Thế giới phát triển phần mềm đã âm thầm rời xa kiến trúc REST gốc của Roy Fielding, bất chấp những tuyên bố rộng rãi về việc xây dựng các RESTful APIs. Những gì mà hầu hết các lập trình viên gọi là REST ngày nay có rất ít điểm tương đồng với các nguyên tắc học thuật được nêu trong luận án năm 2000 của Fielding định nghĩa về Representational State Transfer.
Sự Hiểu Lầm Lớn Về REST
Vấn đề cốt lõi nằm ở việc hiểu sai cơ bản về ý nghĩa thực sự của REST. REST thực sự yêu cầu HATEOAS (Hypermedia as the Engine of Application State), nơi các client khám phá các hành động có sẵn một cách động thông qua các liên kết hypermedia được nhúng trong phản hồi của server. Thay vì hardcode các API endpoint, các client nên điều hướng APIs như người dùng duyệt website - theo các liên kết được cung cấp bởi server.
Hầu hết các REST APIs hiện đại thực chất là các hệ thống kiểu RPC tình cờ sử dụng HTTP verbs và JSON. Chúng yêu cầu tài liệu mở rộng, URLs được hardcode và sự kết nối chặt chẽ giữa client và server. Cách tiếp cận này mâu thuẫn với tầm nhìn của Fielding về các hệ thống tự khám phá và có thể phát triển.
HATEOAS: Một nguyên tắc REST yêu cầu các client khám phá các hành động API thông qua hyperlinks trong phản hồi, thay vì dựa vào tài liệu
Sáu ràng buộc REST của Fielding:
- Sử dụng Uniform Resource Identifiers (URIs) cho tất cả các tài nguyên
- Tuân thủ các tiêu chuẩn HTTP hiện có mà không thay đổi
- Định nghĩa việc hiểu dữ liệu thông qua các loại media và liên kết, không phải cấu trúc URI
- Client không nên hardcode các đường dẫn URI mà phải khám phá chúng một cách động
- Các phân loại nội bộ của server phải không thể nhìn thấy đối với client
- Client chỉ cần một điểm vào duy nhất và kiến thức về các loại media tiêu chuẩn
Tại Sao Các Lập Trình Viên Chọn Thực Dụng Thay Vì Thuần Túy
Cộng đồng đã phần lớn chấp nhận sự lệch hướng này vì những lý do thực tế. Việc xây dựng các APIs thực sự RESTful với HATEOAS tạo ra chi phí phụ và độ phức tạp đáng kể mà nhiều nhóm thấy không thể biện minh được. Gánh nặng nhận thức của việc tạo ra các client được điều khiển bởi hypermedia thường vượt quá những lợi ích lý thuyết của việc kết nối lỏng lẻo và khả năng phát triển.
Việc áp dụng rộng rãi một phong cách đơn giản hơn, giống RPC qua HTTP có thể được quy cho những đánh đổi thực tế trong công cụ và trải nghiệm lập trình viên.
Các công cụ như OpenAPI và Swagger đã làm cho việc tạo mã client, tạo tài liệu và xác thực yêu cầu cho các HTTP APIs truyền thống trở nên dễ dàng hơn. Những lợi ích năng suất tức thì này chứng tỏ có giá trị hơn đối với hầu hết các nhóm so với những lợi ích kiến trúc trừu tượng của REST thuần túy.
Đặc điểm phổ biến của API "REST" (Thực tế không phải RESTful):
- JSON qua HTTP với các thao tác CRUD
- Ánh xạ tới các động từ POST/GET/PUT/DELETE
- Các mẫu URI được mã hóa cứng như
/users/{id}/orders - Yêu cầu tài liệu API chi tiết
- Liên kết chặt chẽ giữa client và server
- Không có điều khiển hypermedia hoặc khám phá liên kết
Ngoại Lệ Trình Duyệt
Thú vị thay, việc triển khai thành công nhất các nguyên tắc REST xảy ra hàng ngày thông qua các trình duyệt web. Khi bạn nhấp vào các liên kết trên website, bạn đang trải nghiệm HATEOAS trong thực tế - trình duyệt khám phá các hành động có sẵn thông qua hyperlinks mà không cần kiến thức trước về cấu trúc của trang web. Điều này hoạt động vì con người cung cấp trí thông minh để diễn giải và điều hướng hypermedia.
Tuy nhiên, mô hình có con người trong vòng lặp này không dịch chuyển tốt sang giao tiếp máy-với-máy, nơi các client tự động cần các giao diện có thể dự đoán và được tài liệu hóa tốt để hoạt động đáng tin cậy.
Tiến Lên Với Thuật Ngữ Trung Thực
Thay vì tiếp tục cuộc chiến ngữ nghĩa về định nghĩa REST, nhiều lập trình viên hiện nay thích gọi những sáng tạo của họ là HTTP APIs hoặc JSON APIs. Việc gắn nhãn trung thực này tránh được gánh nặng học thuật trong khi truyền đạt rõ ràng những gì hệ thống thực sự cung cấp.
Ngành công nghiệp về cơ bản đã bỏ phiếu bằng bàn phím của họ, chọn các giải pháp thực tế hơn là sự thuần túy kiến trúc. Trong khi những người theo chủ nghĩa thuần túy có thể than thở về sự lệch hướng này khỏi tầm nhìn của Fielding, việc áp dụng rộng rãi các REST-ish APIs cho thấy chúng phục vụ nhu cầu phát triển thực tế tốt hơn so với những đối tác đúng về mặt học thuật.
Tham khảo: Most RESTful APIs aren't really RESTful