REST và HATEOAS có phải là một kiến ​​trúc tốt cho các dịch vụ web không?

Nếu tôi hiểu chính xác, REST đã được Roy Fielding chính thức hóa thành một mô hình mô tả về kiến ​​trúc của web. AFAIK Fielding đã không tuyên bố REST là tốt, ông chỉ mô tả kiến ​​trúc thực tế của web. Vào thời điểm này, web đã chứng minh một hệ thống siêu văn bản phân tán thành công to lớn, vì vậy loại xác thực REST này là một kiến ​​trúc thành công cho miền hypermedia phân tán chủ yếu được điều hướng và tiêu thụ bởi con người.

Các dịch vụ web REST đã được tạo bằng cách áp dụng kiến ​​trúc REST cho API. Nhưng có thực sự có lý do nào để nghĩ REST là một kiến ​​trúc mong muốn cho miền này không? Cụ thể hơn, có bằng chứng nào cho thấy HATEOAS là một nguyên tắc thiết kế có lợi cho giao tiếp giữa máy với máy không?

Mối quan tâm của tôi là HATEOAS có ý nghĩa đối với hypermedia vì có một số loại nội dung nổi tiếng (HTML, hình ảnh, video, v.v.) và khách hàng biết cách tiêu thụ chúng. Nhưng đối với API, các loại nội dung rất cụ thể và chỉ có thể được khách hàng sử dụng theo cách có ý nghĩa nếu khách hàng được lập trình cụ thể để tiêu thụ chúng. Việc trả lại một URL cho máy khách không tự nó làm cho máy khách có thể sử dụng tài nguyên được chỉ định.

AFAIK Fielding đã không tuyên bố REST là tốt, ông chỉ mô tả kiến ​​trúc thực tế của web.

Điều đó nhấn mạnh nó một chút, tôi sẽ nghĩ. Cuối cùng, REST là một bảng liệt kê của phong cách kiến ​​trúc mà Fielding đang sử dụng với tư cách là kiến ​​trúc sư trưởng của thông số HTTP / 1.1 .

Nhưng có thực sự có lý do nào để nghĩ REST là một kiến ​​trúc mong muốn cho miền này không? Có bằng chứng nào cho thấy HATEOAS là một nguyên tắc thiết kế có lợi cho giao tiếp giữa máy với máy không?

"Nó phụ thuộc". HATEOAS là một phần của ràng buộc giao diện thống nhất của REST.

Bằng cách áp dụng nguyên tắc công nghệ phần mềm về tính tổng quát cho giao diện thành phần, kiến ​​trúc hệ thống tổng thể được đơn giản hóa và khả năng hiển thị của các tương tác được cải thiện. Việc triển khai được tách rời khỏi các dịch vụ mà họ cung cấp, điều này khuyến khích khả năng phát triển độc lập. Mặc dù vậy, sự đánh đổi là một giao diện thống nhất làm giảm hiệu quả, vì thông tin được truyền dưới dạng chuẩn chứ không phải là giao diện cụ thể cho nhu cầu của ứng dụng. Giao diện REST được thiết kế để có hiệu quả cho việc truyền dữ liệu hypermedia hạt lớn, tối ưu hóa cho trường hợp phổ biến của Web, nhưng dẫn đến giao diện không tối ưu cho các hình thức tương tác kiến ​​trúc khác.

Vì vậy, hãy suy nghĩ một chút về điều này có nghĩa là gì. Khi tôi gặp sự cố với bộ định tuyến không dây của mình, tôi có thể giao tiếp với nó bằng cùng một trình duyệt mà tôi sử dụng để gửi câu trả lời cho stackexchange. Cụ thể, không quan trọng tôi đang sử dụng trình duyệt nào, hoặc trình duyệt của tôi có một vài cập nhật phía sau (hoặc trước) về những gì bộ định tuyến đang mong đợi. Không có vấn đề gì khi tổ chức kỹ thuật viết trình duyệt hoàn toàn độc lập với tổ chức đã tạo giao diện bộ định tuyến.

Nó chỉ hoạt động .

Tất nhiên, nó không phải là phổ quát. Fielding, năm 2008 , đã viết:

Điều đó không có nghĩa là tôi nghĩ mọi người nên thiết kế hệ thống của riêng mình theo phong cách kiến ​​trúc REST. REST dành cho các ứng dụng dựa trên mạng tồn tại lâu dài trải rộng trên nhiều tổ chức. Nếu bạn không thấy sự cần thiết cho các ràng buộc, thì đừng sử dụng chúng.

Các ràng buộc hình thành phong cách kiến ​​trúc REST đã được chọn cho các thuộc tính mà chúng tạo ra; nếu các thuộc tính đó không có giá trị đối với trường hợp sử dụng của bạn, thì bạn hoàn toàn nên xem xét loại bỏ các ràng buộc tương ứng.

Trường hợp máy với máy gặp khó khăn, là bạn đã mất khả năng của con người để phù hợp với ngữ nghĩa được cung cấp bởi các đại diện. Các khách hàng có thể nhận được bằng cách chỉ biết các loại phương tiện, nhưng chúng ta thường có một con người nhìn vào các tín hiệu ngữ nghĩa để rút ra ý nghĩa.

lược đồ.org là một phần trong nỗ lực tạo ra một từ vựng có thể đọc được bằng máy; các tác nhân máy sử dụng máy khách để tìm các gợi ý ngữ nghĩa và áp dụng sự hiểu biết của riêng nó về ý nghĩa để chọn các hành động chính xác cần thực hiện.

Nhưng nó hoạt động; bạn cần đầu tư phát triển các đại diện thân thiện với máy của các tài nguyên của mình và đảm bảo rằng các đại diện đó vẫn tương thích tiến và lùi, để khách hàng có thể được phát triển độc lập.

Khi một tổ chức duy nhất kiểm soát cả máy khách và máy chủ, lợi ích của sự độc lập này nhỏ hơn rất nhiều, trong trường hợp đó, ràng buộc có thể không phải là một lựa chọn kiến ​​trúc phù hợp.

Không, 'REST đầy đủ' không phải là tuyệt vời.

Bằng chứng là việc thiếu những người triển khai HATEOS trong các API mạnh hơn và các đối số vô tận về việc sử dụng động từ HTTP cho một cuộc gọi cụ thể.

Nhưng bạn phải nhận ra tại sao REST lại phổ biến đến vậy. Trước khi áp dụng, đã có nhiều giao thức phức tạp điên rồ khác nhau như ebXML và SOAP liên quan đến các xác nhận, thời gian chờ, Id hội thoại và trạng thái.

Bắt những thứ này lên và chạy và sau đó giải thích chúng cho người tiêu dùng của api là một nhiệm vụ khó khăn. "tại sao tôi không thực hiện NHẬN với id tôi muốn trong chuỗi truy vấn và bạn gửi cho tôi dữ liệu?" là một câu hỏi rõ ràng và phổ biến.

Sau đó, vấn đề thứ hai là XML, javascript không hiểu nó, các lược đồ là một vấn đề khó khăn và bạn sẽ kết thúc với các tệp txt lớn chủ yếu bao gồm <MyLongObjectName>. Vì vậy, mọi người bắt đầu sử dụng JSON thay thế.

Bây giờ REST có một chút sùng bái xung quanh nó, nhưng vì các quy tắc rất mơ hồ nên nó không ngăn bạn gõ một API có thể sử dụng, đủ đơn giản để người tiêu dùng sẽ 'lấy nó' và sử dụng nó mà không cần 6 tháng khi lên máy bay quá trình.

Cần lưu ý rằng Roy không phải là nhà phát minh ban đầu của hầu hết các nguyên tắc của REST, ông kết hợp nhiều nguyên tắc được biết là hoạt động trong các hệ thống trước đó để giải quyết các vấn đề cụ thể khác nhau. REST chỉ đơn giản là kết luận tự nhiên của việc áp dụng các nguyên tắc này trong một kiến ​​trúc duy nhất.

Ngay cả trước khi Roy Fielding viết luận văn về REST , HTTP đã được thiết kế xung quanh các nguyên tắc mà sau này được gọi là REST. Trong phần kết luận của luận án , ông đã viết:

Khi bắt đầu những nỗ lực của chúng tôi trong Lực lượng đặc nhiệm kỹ thuật Internet để xác định Giao thức truyền siêu văn bản hiện tại (HTTP / 1.0) [19] và thiết kế các phần mở rộng cho các tiêu chuẩn mới của HTTP / 1.1 [42] và Mã định danh tài nguyên đồng nhất (URI) [21 ], Tôi nhận ra sự cần thiết của một mô hình về cách World Wide Web hoạt động. Mô hình lý tưởng hóa các tương tác này trong một ứng dụng Web tổng thể, được gọi là kiểu kiến ​​trúc Chuyển giao trạng thái đại diện (REST), trở thành nền tảng cho kiến ​​trúc Web hiện đại, cung cấp các nguyên tắc hướng dẫn theo đó các lỗ hổng trong kiến ​​trúc có sẵn có thể được xác định và mở rộng xác nhận trước khi triển khai .

REST và HATEOS phù hợp với vấn đề được thiết kế cho:

REST là một tập hợp các ràng buộc kiến ​​trúc nhằm cố gắng giảm thiểu độ trễ và giao tiếp mạng đồng thời tối đa hóa tính độc lập và khả năng mở rộng của việc triển khai thành phần . Điều này đạt được bằng cách đặt các ràng buộc về ngữ nghĩa kết nối trong đó các kiểu khác đã tập trung vào ngữ nghĩa thành phần. REST cho phép lưu trữ và tái sử dụng các tương tác, khả năng thay thế linh hoạt của các thành phần và xử lý các hành động của các trung gian , do đó đáp ứng nhu cầu của một hệ thống hypermedia phân tán trên quy mô Internet.

Tuy nhiên, cần lưu ý rằng Web và REST không nhất thiết phải phù hợp với mọi vấn đề:

Tương tự, các tiện ích mở rộng được đề xuất có thể được so sánh với REST để xem chúng có phù hợp với kiến ​​trúc không; nếu không, sẽ hiệu quả hơn khi chuyển hướng chức năng đó sang một hệ thống chạy song song với kiểu kiến ​​trúc phù hợp hơn.

Vì vậy, nếu câu hỏi của bạn là "REST và HATEOAS có phải là một kiến ​​trúc tốt cho các dịch vụ web không?" sau đó, câu trả lời chỉ đơn giản là "có, nó là một kiến ​​trúc tốt cho các dịch vụ web". Vấn đề thực sự là liệu tất cả các vấn đề mà mọi người đã cố gắng giải quyết bằng cách trang bị thêm chúng vào các ràng buộc web, thực sự nên là dịch vụ web ngay từ đầu.

Có nhiều API thực sự không phù hợp với REST. Các API không cần loại khả năng mở rộng mà REST được thiết kế để giải quyết, không được sử dụng bởi nhiều tổ chức có thể phát triển độc lập và không cần tồn tại lâu; đối với những vấn đề này, các ràng buộc REST chỉ là một bó.

Nhưng có thực sự có lý do nào để nghĩ REST là một kiến ​​trúc mong muốn cho miền này không? Cụ thể hơn, có bằng chứng nào cho thấy HATEOAS là một nguyên tắc thiết kế có lợi cho giao tiếp giữa máy với máy không?

Bằng chứng là sự thành công của Web trong việc giải quyết nhiều vấn đề của mọi người. REST là một kiến ​​trúc lai, kết hợp các thiết kế của nhiều phong cách kiến ​​trúc trước đó. Nhiều miền có vấn đề không có tất cả các yêu cầu của Web và không cần tuân theo tất cả các ràng buộc của REST để hoạt động tốt. Đây là lý do tại sao có nhiều kiến ​​trúc thành công hoạt động tốt bằng cách chỉ áp dụng một số phần của REST chứ không phải các phần khác. Ví dụ, HATEOAS và Giao diện thống nhất là các nguyên tắc thường bị bỏ qua bởi các API không cần vượt qua các ranh giới tổ chức và hệ thống có thời gian khấu hao tương đối ngắn.

Trong phần trình bày của Fielding trên Adobe Experience Manager:

REST KHÔNG phải là một kiến ​​trúc!

Phần còn lại là một phong cách kiến ​​trúc, đó là sự trừu tượng của các kiến ​​trúc khác nhau tồn tại trên internet.

REST là sự tích lũy của các ràng buộc thiết kế để tạo ra các thuộc tính kiến ​​trúc

REST là một từ thông dụng và mọi người đều muốn có API RESTful. Trong thực tế, khi mọi người phải đối mặt với các ràng buộc REST, họ đã bỏ một số các ràng buộc này vì không có nhu cầu hoặc không có lợi ích nào để họ áp dụng tất cả các ràng buộc.

Như bạn đã đề cập, HATEOAS rất hữu ích khi máy khách là trình duyệt web. Khi khách hàng là một ứng dụng di động, có thể không quá nhiều. Đó sẽ là một thực tiễn tốt, nhưng cũng có những chi phí liên quan đến việc thiết kế một ứng dụng như vậy, đến mức, ví dụ, nhóm ứng dụng di động và nhóm hỗ trợ đã đồng ý bỏ ràng buộc đó. Và điều đó có ý nghĩa bởi vì cả hai đội không được ghép lỏng lẻo vì họ làm việc cho cùng một công ty.

REST trong AEM

Nếu điều bạn muốn là tạo ra một dịch vụ được sử dụng bởi một máy chủ khác, thì xmlrpc là lựa chọn chính xác. Nếu những gì bạn muốn là một dịch vụ được sử dụng bởi các khách hàng mỏng hoặc các thiết bị năng lượng thấp .. hoặc các khách hàng không xác định qua internet mở thì có lẽ nên xem xét việc sử dụng json. Nhưng hãy nhớ rằng, json là một ký hiệu kém hơn để chỉ định dữ liệu chung, khi so sánh với xml.