Khả năng phát hiện thời gian chạy API RESTful / thiết kế ứng dụng khách HATEOAS

Đối với một công ty khởi nghiệp SaaS mà tôi tham gia, tôi đang xây dựng cả API web RESTful và một vài ứng dụng khách trên các nền tảng khác nhau sử dụng nó. Tôi nghĩ rằng tôi đã tìm ra API, nhưng bây giờ tôi đang chuyển sang các khách hàng. Khi tôi đã đọc về REST, tôi thấy rằng phần quan trọng của REST là khám phá , nhưng dường như có rất nhiều tranh luận giữa hai cách hiểu khác nhau về ý nghĩa thực sự của khám phá:

1. Khám phá của nhà phát triển : Nhà phát triển mã hóa số lượng lớn các chi tiết API vào máy khách, chẳng hạn như URI của tài nguyên, các tham số truy vấn, các phương thức HTTP được hỗ trợ và các chi tiết khác mà họ đã phát hiện được thông qua việc duyệt tài liệu và thử nghiệm với các phản hồi của API. Loại phát hiện này IMHO yêu cầu liên kết mát mẻ và câu hỏi lập phiên bản API, đồng thời dẫn đến việc ghép nối mã máy khách với API. Có vẻ như không tốt hơn nhiều so với việc sử dụng một bộ sưu tập được ghi chép đầy đủ về RPC.

2. Khám phá thời gian chạy - Bản thân ứng dụng khách có thể tìm ra mọi thứ nó cần với ít hoặc không có thông tin ngoài băng tần (có lẽ, chỉ có kiến ​​thức về các loại phương tiện mà API xử lý.) Các liên kết có thể nóng. Nhưng để làm cho API hoạt động hiệu quả, dường như cần có nhiều mẫu liên kết cho các tham số truy vấn, điều này làm cho thông tin ngoài dải trở lại. Có thể có những khó khăn khác mà tôi chưa nghĩ đến vì tôi chưa đã đến thời điểm đó trong quá trình phát triển. Nhưng tôi thích ý tưởng về khớp nối lỏng lẻo.

Khám phá thời gian chạy có vẻ là chén thánh của REST, nhưng tôi đang thấy cuộc thảo luận nhỏ quý giá về cách triển khai một ứng dụng khách như vậy. Hầu như tất cả các nguồn REST mà tôi đã tìm thấy dường như giả định rằng Nhà phát triển khám phá. Có ai biết về một số tài nguyên khám phá Thời gian chạy không? Thực hành tốt nhất? Ví dụ hoặc thư viện với mã thực? Tôi đang làm việc trong PHP (Zend Framework) cho một khách hàng. Objective-C (iOS) cho cái còn lại.

Khám phá Runtime có phải là một mục tiêu thực tế, với bộ công cụ và kiến ​​thức hiện tại trong cộng đồng nhà phát triển không? Tôi có thể viết ứng dụng khách của mình để xử lý tất cả các URI theo cách không rõ ràng, nhưng làm thế nào để làm điều này hiệu quả nhất là một câu hỏi, đặc biệt là trên các kết nối băng thông thấp. Dù sao đi nữa, URI chỉ là một phần của phương trình. Điều gì về tạo mẫu liên kết trong ngữ cảnh Thời gian chạy? Làm thế nào về việc giao tiếp những phương pháp nào được hỗ trợ, ngoài việc đưa ra rất nhiều yêu cầu TÙY CHỌN?

Đây chắc chắn là một loại hạt khó bẻ. Tại Google, chúng tôi đã triển khai Dịch vụ khám phá của mình mà tất cả các API mới của chúng tôi đều được xây dựng dựa trên đó. Phiên bản TL; DR là chúng tôi tạo một thông số kỹ thuật giống như Lược đồ JSON mà khách hàng của chúng tôi có thể phân tích cú pháp - nhiều trong số chúng động.

Kết quả đó đồng nghĩa với việc nâng cấp SDK dễ dàng hơn cho nhà phát triển và bảo trì dễ dàng / tốt hơn cho chúng tôi.

Không có nghĩa là giải pháp hoàn hảo, nhưng nhiều nhà phát triển của chúng tôi dường như thích.

Xem liên kết để biết thêm chi tiết (và đảm bảo xem vid.)

Hấp dẫn. Những gì bạn đang mô tả về cơ bản là nguyên tắc HATEOAS. Bạn hỏi HATEOAS là gì? Đọc phần này: http://en.wikipedia.org/wiki/HATEOAS

Theo thuật ngữ của giáo dân, HATEOAS có nghĩa là liên kết theo sau. Cách tiếp cận này tách khách hàng của bạn khỏi URL cụ thể và mang lại cho bạn sự linh hoạt để thay đổi API của mình mà không vi phạm bất kỳ ai.

Bạn đã làm công việc nhà của mình và bạn đã đi vào trọng tâm của nó: khám phá thời gian chạy là chén thánh. Đừng đuổi theo nó.

UDDI kể một câu chuyện sâu sắc về khám phá thời gian chạy: http://en.wikipedia.org/wiki/Universal_Description_Discovery_and_Integration

Một trong những yêu cầu cần được đáp ứng trước khi bạn có thể gọi một API là 'RESTful' là bạn phải có thể viết một ứng dụng khách chung trên API đó. Với ứng dụng khách chung, người dùng có thể truy cập tất cả các chức năng của API. Một ứng dụng khách chung là một ứng dụng khách không giả định rằng bất kỳ tài nguyên nào có cấu trúc cụ thể ngoài cấu trúc được xác định bởi loại phương tiện. Ví dụ: trình duyệt web là một ứng dụng khách chung biết cách diễn giải HTML, bao gồm các biểu mẫu HTML, v.v.

Bây giờ, giả sử chúng tôi có API HTTP / JSON cho một cửa hàng trực tuyến và chúng tôi muốn xây dựng một ứng dụng khách HTML / CSS / JavaScript mang đến cho khách hàng trải nghiệm người dùng tuyệt vời. Nó có phải là một lựa chọn thực tế nếu để ứng dụng khách đó là một ứng dụng khách chung không? Không. Chúng tôi muốn cung cấp giao diện cụ thể cho mọi phần tử dữ liệu cụ thể và mọi trạng thái ứng dụng cụ thể. Chúng tôi không muốn đưa tất cả kiến ​​thức về các thông tin cụ thể về bản trình bày này vào API, ngược lại, khách hàng nên xác định giao diện và API chỉ nên mang dữ liệu. Điều này ngụ ý rằng máy khách có sự ghép nối được mã hóa cứng của các phần tử tài nguyên cụ thể với các bố cục cụ thể và các tương tác của người dùng.

Đây có phải là sự kết thúc của HATEOAS và do đó là kết thúc của REST? Có và không .

Có , bởi vì nếu chúng tôi mã hóa kiến ​​thức về API vào máy khách, chúng tôi sẽ mất lợi ích của HATEOAS: các thay đổi phía máy chủ có thể phá vỡ máy khách.

Không , vì hai lý do:

1. "RESTful" là thuộc tính của API, không phải của ứng dụng khách. Về lý thuyết , miễn là có thể xây dựng một ứng dụng khách chung cung cấp tất cả các khả năng của API, thì API có thể được gọi là RESTful. Việc khách hàng không tuân theo các quy tắc không phải là lỗi của API. Thực tế là một ứng dụng khách chung sẽ có trải nghiệm người dùng tệ hại không phải là một vấn đề. Tại sao điều quan trọng là phải biết rằng có thể có một khách hàng chung, nếu chúng ta thực sự không có khách hàng chung đó? Điều này đưa tôi đến lý do thứ hai:
2. API RESTful cung cấp cho khách hàng tùy chọn để chọn mức độ chung mà họ muốn, tức là mức độ linh hoạt đối với các thay đổi phía máy chủ mà họ muốn. Những khách hàng cần cung cấp trải nghiệm người dùng tuyệt vời vẫn có thể phục hồi trước các thay đổi của URI, với các thay đổi trong giá trị mặc định và hơn thế nữa. Khách hàng thực hiện các công việc hàng loạt mà không có sự tương tác của người dùng có thể có khả năng chống lại các loại thay đổi khác.

Nếu bạn quan tâm đến các ví dụ thực tế, hãy xem bài báo JAREST của tôi . Phần cuối cùng là về HATEOAS. Bạn sẽ thấy rằng với JAREST, ngay cả những máy khách có tính tương tác cao và hấp dẫn về mặt hình ảnh cũng có thể khá bền với những thay đổi phía máy chủ, mặc dù không phải 100%.

Tôi nghĩ điểm quan trọng về HATEOAS không phải là nó nằm ở phía máy khách chén thánh nào đó, mà là nó cách ly máy khách khỏi các thay đổi của URI - giả sử bạn đang sử dụng Mối quan hệ liên kết đã biết (hoặc do nhà phát triển phát hiện tùy chỉnh) sẽ cho phép hệ thống biết liên kết nào cho một đối tượng là biểu mẫu có thể chỉnh sửa. Điểm quan trọng là sử dụng loại emdia nhận biết siêu phương tiện (ví dụ: HTML, XHTML, v.v.).

Bạn viết:

Để làm cho API hoạt động hiệu quả, dường như cần có nhiều mẫu liên kết cho các tham số truy vấn, điều này làm cho thông tin ngoài dải trở lại.

Nếu mẫu liên kết đó được cung cấp trong yêu cầu trước đó, thì sẽ không có thông tin ngoài băng tần. Ví dụ: một biểu mẫu tìm kiếm HTML sử dụng liên kết templating ( /search?q=%@) để tạo URL ( /search?q=hateoas), nhưng không có gì được khách hàng (trình duyệt web) biết ngoài cách sử dụng các biểu mẫu HTML và GET.