10 Cách Tốt Nhất Để Viết Các Rest Api Node.js

: blog.risingstack.com/10-best-practices-for-writing-node-js-rest-apis/

Một trong những trường hợp sử dụng thông dụng nhất của chúng tôi là viết các RESTful API. Khi chúng tôi đang hỗ trợ khách hàng bằng cách tìm các vấn đề trong ứng dụng của họ với Trace (công cụ giám sát chúng tôi thì phát hiện ra rằng có rất nhiều các developer đang gặp vấn đề với REST API. Do đó, tôi mong rằng các cách chúng tôi sử dụng với RisingStack sẽ giúp được bạn:

Hãy tưởng tượng rằng bạn đang xây dựng một RESTful API chúng tôi để tạo, cập nhật, gọi thông tin hay xóa người dùng. Với các tính năng đó HTTP đã cung cấp một bộ đầy đủ các phương thức: và.

Cách tối ưu nhất là các API route của bạn chỉ nên sử dụng danh từ như là các định danh tài nguyên. Các route khi đó sẽ trông như thế này:

• POST /user hay PUT /user:/id để tạo người dùng mới.
• GET /user để lấy danh sách người dùng.
• GET /user/:id để lấy thông tin của một người dùng.
• PATCH /user/:id để sửa một bản ghi người dùng đã có.
• DELETE /user/:id để xóa một người dùng.

Các API route của bạn chỉ nên sử dụng danh từ như là các định danh tài nguyên.

Nếu có gì xảy ra khi server đang xử lý một request, bạn cần thiết lập đúng mã status trong response trả về:

• 2xx, nếu không có lỗi (thành công).
• 3xx, nếu tài nguyên đã bị gỡ bỏ.
• 4xx, nếu request không được thực hiện do lỗi client.
• 5xx, nếu có lỗi ở phía API (một ngoại lệ nào đó xảy ra,...).

Nếu bạn sử dụng Express, thiết lập mã status khá dễ dàng: res.status(500).send({error: 'Internal server error happened'}). Với Restify: res.status(201).

Bạn có thể xem danh sách đầy đủ các mã status ở đây.

Để đính kèm các metadata vào payload bạn sắp gửi, sử dụng HTTP header. Các header sẽ bao gồm các thông tin:

Đây là một danh sách các header HTTP đã chuẩn hóa.

Nếu bạn cần thiết lập bất cứ metadata custom nào trong header, hãy thêm tiền tố X vào phía trước. Ví dụ, nếu bạn đang sử dụng CSRF token, cách thông thường (nhưng không chuẩn) là đặt tên kiểu X-Csrf-Token. Tuy nhiên, theo RFC 6648 thì sẽ gây khó hiểu. Với các API mới không nên sử dụng các tên header dễ gây xung đột với các ứng dụng khác. Ví dụ, OpenStack sẽ tự động thêm tiền tố vào header với OpenStack:

Chú ý rằng các chuẩn HTTP không định nghĩa bất cứ giới hạn kích cỡ nào trong header. Tuy nhiên chúng tôi (kể từ lúc viết bài này) đã buộc object header nhận một giới hạn kích thước là 80kB cho lý do thực tế.

Không cho phép kích thước tổng của các HTTP header (bao gồm các mã status) vượt quá Điều này giúp bảo vệ các embedder khỏi các cuộc tấn công từ-chối-dịch-vụ, khi kẻ tấn công sẽ gửi các header không-kết-thúc cho các embedder lưu giữ buffering.

Express, Koa hay Hapi có thể được sử dụng để tạo ra các ứng dụng nền web, chúng hỗ trợ templating và rendering. Nếu ứng dụng của bạn cần cung cấp dịch vụ phía người dùng, hãy thử dùng một trong số chúng và tận hưởng thành quả.

Ở một khía cạnh khác, Restify tập trung hoàn toàn vào việc giúp bạn xây dựng các dịch vụ REST. Restify tồn tại để giúp bạn xây dựng các dịch vụ API "chuẩn" đáng kể, dễ bảo trì. Restify cũng đi kèm với công cụ hỗ trợ tự động DTrace.

Về mức độ phủ sóng thì Restify đang được sử dụng trong rất nhiều các ứng dụng, điển hình như npm hay Netflix.

Restify tồn tại để giúp bạn xây dựng các dịch vụ API "chuẩn" đáng kể, dễ bảo trì.

@RisingStack

Một trong những cách hay nhất để test các REST API là xem chúng như các black-box.

. Do đó, sẽ không cần mock dependency nào, hệ thống sẽ được test như một thể duy nhất.

Để giúp bạn test các REST API theo phương pháp black-box này, ta sẽ sử dụng module supertest.

Thông thường, test thường được viết làm sao để chúng tạo ra càng ít các giả định cho trang thái hệ thống càng tốt. Tuy vậy, trong một vài bối cảnh bạn cần biết chính xác trạng thái của hệ thống, bạn có thể tạo các assertion và đạt được mức độ test cao hơn.

Tùy thuộc vào nhu cầu của bạn, bạn có thể phổ biến cơ sở dữ liệu với các dữ liệu test theo một trong các cách sau:

• Chạy kịch bản test black-box theo một tập con đã biết của dữ liệu production.
• Phổ biến database với dữ liệu thủ công trước khi chạy các test case.

Dĩ nhiên, black-box test không đồng nghĩa với việc bạn không cần viết unit test. Trong hầu hết các trường hợp, bạn vẫn cần viết unit test cho các API.

Các API phải là phi trạng thái, bởi vậy xác thực cũng tương tự. JWT (Json Web Token) chính là ý tưởng. JWT gồm 3 phần:

• : chứa kiểu của token, thuật toán hash.
• : Chứa các yêu cầu.
• .

Thêm xác thực loại JWT vào ứng dụng khá đơn giản và nhanh chóng:

Sau khi thêm, endpoint API đã được bảo vệ với JWT. Để truy cập vào các endpoint được bảo vệ, bạn cần phải cung cấp token trong trường header Authorization:

Hãy chú ý một điều rằng module JWT trên không phụ thuộc bất cứ lớp database nào, do tất cả token JWT có cơ chế tự xác thực, và chúng còn bao gồm cả giá trị thời gian sống.

Trong bài viết trước, chúng tôi đã giải thích chi tiết về phương pháp xác thực web. Tôi khuyến nghị các bạn hãy tìm hiểu thêm.

Các request có điều kiện là các request HTTP được thực thi theo các cách khác nhau, phụ thuộc vào các header HTTP cụ thể. bạn có thể xem các header này như là điều kiện tiên quyết: nếu chúng gặp nhau, các request sẽ được thực thi theo các cách khác nhau.

Các request có điều kiện là các request HTTP được thực thi theo các cách khác nhau, phụ thuộc vào các HTTP cụ thể

@RisingStack

Các header này sẽ cố gắng kiểm tra liệu một phiên bản tài nguyên được lưu trữ trên server có trùng với phiên bản của cùng một tài nguyên hay không. Vì lý do này, các header có thể là:

• Timestamp của lần thay đổi gần nhất.
• Một tag nào đấy, khác nhau tùy vào phiên bản.

Chúng chính là:

• Last-Modified ( để chỉ ra lần gần nhất dữ liệu được chỉnh sửa ).
• Etag ( để chỉ ra tag ).
• If-Modified-Since (sử dụng với header Last-Modified ).
• If-None-Match (sử dụng với header Etag ).

Client có thể thiết lập header If-Modified-Since và If-None-Match một lần khi nó cố gắng gửi request với cùng tài nguyên. Nếu response trả về là giống nhau, server chỉ đơn giản là phản hồi lại với mã status 304 - Not Modified và không gửi lại tài nguyên nữa.

Rate limiting được sử dụng để điều khiển việc một cunsumer có thể gửi đến API bao nhiêu request.

Để nói với API có bao nhiêu request đã được gửi, trong header hãy thiết lập như sau:

• X-Rate-Limit-Limit: số lượng các request được cho phép trong một khoảng thời gian cho trước.
• X-Rate-Limit-Remaining: the number of requests remaining in the same interval. số lượng các request cong lại trong cùng khoảng thời gian.
• X-Rate-Limit-Reset: thời gian mà rate limit được thiết lập.

Phần lớn các framework HTTP hỗ trợ bằng các công cụ bên ngoài hay là các plugin. Ví dụ, nếu bạn sử dụng Koa, hãy thử package koa-ratelimit.

Chú ý rằng thời gian window có thể thay đổi tùy vào các nhà cung cấp API khác nhau - ví dụ đối với Github là 1 giờ, trong khi Twitter là 15 phút.

Các API được viết ra để mọi người có thể sử dụng chúng, hưởng lợi ích từ chúng. Do đó việc cung cấp các document đi kèm với các REST API là điều tối cần thiết.

Các project open-source sau đây có thể giúp bạn tạo ra các document cho API:

Nếu bạn muốn sử dụng sản phẩm đã host, bạn có thể dùng Apiary.

Trong vài năm vừa qua, hai ngôn ngữ truy vấn lớn cho các API đã mọc lên: GraphQL của Facebook và Falcor của Netflix. Tại sao ta lại cần chúng đến thế?

Tưởng tượng một request tài nguyên RESTful như sau:

Nếu bạn có dự định bắt đầu phát triển một REST API chúng tôi hoặc tạo một phiên bản mới của API cũ, chúng tôi đã thu thập 4 ví dụ thực tế để giúp bạn:

Tôi mong là qua bài viết này, các bạn đã có một cái nhìn tổng thể về các API, tại sao các API nên được viết bằng Node.js.

Nguồn Techtalk.vn