REST API (Representational State Transfer API)

1. Tổng quan

A. Định nghĩa

API theo phong cách kiến trúc dựa trên HTTP, định danh tài nguyên (Resource) bằng URI, biểu diễn hành vi bằng phương thức HTTP, và trao đổi trạng thái của tài nguyên dưới dạng biểu diễn (Representation) như JSON·XML. Được Roy Fielding đề xuất trong luận án tiến sĩ năm 2000.

Điều cần nhấn mạnh ở REST là nó không phải một công nghệ hay đặc tả cụ thể mà là phong cách kiến trúc (tập hợp các ràng buộc). Tức là nó không nói "hãy dùng giao thức này", mà là tập hợp nguyên tắc "nếu tuân thủ các ràng buộc này, hệ thống sẽ có khả năng mở rộng và liên kết lỏng như Web". Vì đây là sự khái quát hóa cấu trúc đã thành công ở quy mô lớn của chính Web vào thiết kế API, để hiểu REST cần xem mỗi ràng buộc nhằm đạt được khả năng mở rộng·tính độc lập nào.

B. Bối cảnh ra đời và sự cần thiết

SOAP — tiêu chuẩn dịch vụ web ban đầu — có phong bì XML và bộ đặc tả WS-* nặng nề, khắt khe, trở thành gánh nặng cho các client nhẹ như trình duyệt·di động và cho việc liên kết mở nhanh chóng. Khi Web, di động và MSA lan rộng, điều cần thiết là "một giao diện nhẹ, chuẩn mực mà ai cũng có thể dễ dàng kết nối chỉ cần có HTTP". REST tận dụng nguyên vẹn phương thức, mã trạng thái và cache của HTTP vốn đã được kiểm chứng, nên gánh nặng học đặc tả riêng thấp, và client·server có thể tiến hóa độc lập, nhờ đó trở thành tiêu chuẩn trên thực tế của API mở và nền kinh tế nền tảng.

2. 6 ràng buộc kiến trúc của REST

flowchart LR
  CS[Client-Server] --- ST[Stateless]
  ST --- CA[Cacheable]
  CA --- UI[Uniform Interface]
  UI --- LS[Layered System]
  LS --- COD[Code on Demand]

Mỗi ràng buộc đều có chất lượng riêng mà nó hướng tới; phải hiểu điều này mới thấy được "vì sao lại thiết kế như vậy".

A. Client-Server — Tách biệt mối quan tâm giữa UI (client) và lưu trữ dữ liệu (server), để hai bên dù không biết nội bộ của nhau vẫn có thể phát triển độc lập miễn là giao diện khớp.

B. Stateless (phi trạng thái) — Server không ghi nhớ trạng thái phiên của các yêu cầu trước, mỗi yêu cầu tự chứa mọi thông tin cần thiết để xử lý. Vì server không giữ trạng thái, yêu cầu tới server nào cũng được xử lý, nên mở rộng theo chiều ngang (cân bằng tải) trở nên dễ dàng. Đây là lý do cốt lõi giúp chịu được lưu lượng lớn.

C. Cacheable — Ghi rõ trong phản hồi khả năng được cache, để khi lặp lại cùng một yêu cầu thì cache trung gian·phía client sẽ trả lời. Đây là nền tảng khả năng mở rộng của Web, giúp giảm tải và độ trễ cho server.

D. Uniform Interface (giao diện đồng nhất) — Ràng buộc cốt lõi làm REST ra REST: định danh tài nguyên bằng URI, thao tác tài nguyên thông qua biểu diễn, thông điệp tự mô tả, và chuyển trạng thái bằng siêu liên kết (HATEOAS). Nhờ giao diện nhất quán, client không bị phụ thuộc vào cách hiện thực của một server cụ thể.

E. Layered System — Client không cần biết mình giao tiếp trực tiếp với server cuối hay đi qua proxy·gateway·bộ cân bằng tải trung gian. Có thể tự do chèn thêm các lớp để bổ sung một cách trong suốt các chức năng bảo mật·cache·mở rộng.

F. Code on Demand (tùy chọn) — Ràng buộc tùy chọn duy nhất, cho phép server gửi mã thực thi (ví dụ: script) xuống để mở rộng chức năng của client.

3. Thành phần và phương thức

3 yếu tố của REST là tài nguyên·hành vi·biểu diễn. Tài nguyên tương ứng với "cái gì" (định danh bằng URI), hành vi là "như thế nào" (phương thức HTTP), biểu diễn là "ở định dạng nào" (JSON, v.v.). Ở đây, nguyên lý quan trọng là tính lũy đẳng (idempotency). Phương thức mà gửi cùng một yêu cầu nhiều lần vẫn cho trạng thái kết quả như nhau được gọi là lũy đẳng; điều này quyết định việc gửi lại khi có sự cố mạng có an toàn hay không. GET·PUT·DELETE là lũy đẳng nên thử lại không gây tác dụng phụ, nhưng POST mỗi lần gọi lại tạo tài nguyên mới, không lũy đẳng, nên phải thận trọng khi thiết kế cơ chế thử lại. Ví dụ, nếu việc tạo thanh toán dùng POST thì có nguy cơ thanh toán trùng, cần bổ sung như thêm khóa lũy đẳng (idempotency key) riêng.

4. Mô hình trưởng thành (Richardson Maturity Model)

Đây là mô hình nhìn REST không theo lối nhị phân "tuân thủ hay không" mà theo mức độ REST theo từng bậc. Level 0 là gọi từ xa chỉ dùng HTTP làm đường hầm truyền tải (giống RPC); Level 1 là bậc tách tài nguyên theo URI; Level 2 là bậc sử dụng phương thức·mã trạng thái đúng ý nghĩa, phần lớn thực tế nằm ở đây. Level 3 là HATEOAS, chứa trong phản hồi các liên kết tới hành động có thể làm tiếp theo, để client không mã hóa cứng URI mà đi theo liên kết do server cung cấp, qua đó giảm độ kết dính hơn nữa. "REST đích thực" mà Fielding nói tới là bậc này, nhưng do chi phí hiện thực·tiêu thụ lớn nên trên thực tế Level 2 là chủ đạo.

5. Lưu ý khi thiết kế và hàm ý

• URI là danh từ, hành vi là phương thức: Không đưa động từ vào URI như /getUser mà tách tài nguyên và hành vi thành GET /users/1 để duy trì giao diện đồng nhất.
• Mã trạng thái·phiên bản·bảo mật: Thông báo chính xác kết quả bằng 2xx/4xx/5xx, quản lý phiên bản qua URI·header, bảo vệ xác thực·truyền tải bằng OAuth2·JWT·HTTPS. Nâng cao khả năng sử dụng bằng phân trang·bộ lọc·tài liệu hóa OpenAPI.
• Công nghệ bổ trợ lẫn nhau: Khi client cần linh hoạt yêu cầu chỉ những trường cần thiết thì GraphQL, còn với giao tiếp nội bộ siêu độ trễ thấp thì gRPC có lợi thế hơn. REST là tiêu chuẩn cho liên kết mở·đa dụng và được dùng cùng các công nghệ này với vai trò phân chia.

Tóm tắt một câu: REST API là phong cách kiến trúc phi trạng thái·giao diện đồng nhất định danh tài nguyên bằng URI và biểu diễn hành vi bằng phương thức HTTP; 6 ràng buộc lần lượt nhắm tới mở rộng ngang·tiến hóa độc lập·hiệu năng, và nguyên lý thiết kế của nó được giải thích qua tính lũy đẳng và mô hình trưởng thành (HATEOAS).