Nhu cầu về 'khả năng khám phá' trong API REST là gì khi các máy khách không đủ tiến bộ để sử dụng nó?

Các cuộc nói chuyện khác nhau mà tôi đã xem và hướng dẫn tôi đã quét trên REST dường như nhấn mạnh một thứ gọi là 'khả năng khám phá'. Theo hiểu biết hạn chế của tôi, thuật ngữ này dường như có nghĩa là một khách hàng sẽ có thể đi đến http://URL- và tự động nhận được một danh sách những điều nó có thể làm.

Điều tôi gặp khó khăn trong việc hiểu - đó là 'khách hàng phần mềm' không phải là con người. Chúng chỉ là những chương trình không có kiến ​​thức trực quan để hiểu chính xác phải làm gì với các liên kết được cung cấp. Chỉ mọi người có thể đi đến một trang web và hiểu ý nghĩa của văn bản và các liên kết được trình bày và hành động trên nó.

Vì vậy, điểm có thể khám phá là gì, khi mã máy khách truy cập các URL có thể khám phá đó thực sự không thể làm gì với nó, trừ khi nhà phát triển con người của khách hàng thực sự thử nghiệm các tài nguyên được trình bày? Điều này trông giống như chính xác khi xác định tập hợp các chức năng có sẵn trong sổ tay Tài liệu, chỉ từ một hướng khác và thực sự liên quan đến nhiều công việc hơn cho nhà phát triển. Tại sao cách tiếp cận thứ hai này của việc xác định trước những gì có thể được thực hiện trong một tài liệu bên ngoài các tài nguyên REST thực tế, được coi là kém hơn?

Nhu cầu khám phá có thể không liên quan, nhưng các liên kết cho phép khám phá phục vụ nhiều mục đích hơn. Theo tôi, điều quan trọng nhất trong số này là việc cung cấp URI đầy đủ trong các phản hồi cho khách hàng, có nghĩa là không khách hàng nào sẽ cần phải "soạn" một URI. Điều đó có nghĩa là sẽ không có khách hàng nào cần kiến ​​thức về cách cấu trúc của URI. Và điều đó cho phép các nhà phát triển máy chủ thay đổi lược đồ URI bất cứ khi nào phù hợp với họ vì họ không cần phải xem xét các khách hàng cũ vẫn dựa vào cách cấu trúc cũ của URI.

"Khách hàng" có thể không đủ tiên tiến để sử dụng nó, nhưng người dùng của khách hàng thì có thể. Một khách hàng có thể là một cái gì đó đơn giản như một trình duyệt web, sau khi tất cả. Khả năng khám phá là tất cả về việc cho phép mọi người tìm hiểu và sử dụng API .

Ví dụ: Jenkins (máy chủ CI) có giao diện giống REST. Chuyển đến bất kỳ trang nào, đặt hậu tố URL bằng "/ api" và bạn nhận được một trang mô tả mọi thứ bạn có thể làm. Nó làm cho việc học API trở nên tầm thường. Ví dụ: http://ci.jruby.org sẽ đưa bạn đến máy chủ jenkins cho jruby và http://ci.jruby.org/api sẽ đưa bạn đến api cho trang cụ thể đó.

Tôi đã rất vui khi làm việc với một API có tài liệu rất, rất khó hiểu.

Khi tôi quản lý để nhận được trả lời thực tế từ máy chủ, có thể so sánh tài liệu với trả lời của máy chủ và sử dụng thông tin đó để giải mã tài liệu (và vâng, giải mã nó là thuật ngữ đúng). Vấn đề là nếu một yêu cầu được gửi đến máy chủ không chính xác theo thông số kỹ thuật, bạn sẽ gặp lỗi và với tài liệu không thể đọc được, việc tìm ra cách gửi yêu cầu chính xác là gần như không thể. Ngoài ra còn có các phiên bản khác nhau của tài liệu API không đồng ý với nhau và có thể không đồng ý với chính API; Điều đó không có ích.

Nếu đã có một lệnh mà tôi có thể gửi đến máy chủ, trả về danh sách tất cả các lệnh có thể và cách gửi chính xác, thì điều đó sẽ cực kỳ hữu ích. Khả năng khám phá không chỉ dành cho khách hàng, nó cũng hữu ích cho các nhà phát triển phần mềm.

LƯU Ý: Tôi không phải là chuyên gia về chủ đề này, nhưng tôi đã trải qua một quá trình tương tự để cố gắng điều hòa các sắc thái khác nhau trong cách hiểu của mọi người về "REST" vài năm trước, và đây là điều tôi nhận được từ việc xem xét nó thời gian.

Theo hiểu biết của tôi, điều này bắt nguồn từ Hypermedia của Roy Fielding với tư cách là Công cụ ứng dụng hay còn gọi là "HATEOAS", sau đó trở thành một người tạo ra ý tưởng về "web ngữ nghĩa".

Vì vậy, về cơ bản, và một lần nữa theo tôi hiểu, bạn làm cho ứng dụng RESTful của bạn về cơ bản tự mô tả sao cho người tiêu dùng không cần phải có kiến ​​thức trước về hợp đồng chính thức để sử dụng nội dung / chức năng của bạn. Họ có thể tham gia từ một số điểm cuối gốc mặc định và sau đó đi bộ các liên kết theo ngữ cảnh mà ứng dụng của bạn cung cấp khi người tiêu dùng tương tác. Người tiêu dùng, tất nhiên, có thể là một người hoặc một tác nhân hệ thống.

Nếu bạn chỉ sử dụng "REST" cho các url đẹp được ánh xạ tới các hoạt động CRUD mà người tiêu dùng phải có kiến ​​thức trước và gọi theo hợp đồng nổi tiếng, Roy Fielding sẽ coi đó không phải là RESTful.

Điều đó không có nghĩa là dịch vụ RPC có hương vị REST được thiết lập không thể hữu ích / cải tiến so với mô hình RPC phức tạp hơn và phù hợp với việc sử dụng bị hạn chế / kiểm soát, nhưng những người cứng rắn sẽ nhìn xuống mũi của họ và coi đó là sự thoái hóa / không thực sự REST.