Яка потреба у «відкритті» в API REST, коли клієнти недостатньо розвинені, щоб скористатися ним?

Різні переговори, які я переглянув, і підручники, які я сканував на REST, схоже, підкреслюють щось, що називається "відкриття". На моє обмежене розуміння, термін, схоже, означає, що клієнт повинен мати можливість перейти http://URL- і автоматично отримати список речей, які він може зробити.

Що я маю проблеми з розумінням - це те, що «клієнти програмного забезпечення» - це не люди. Це просто програми, які не мають інтуїтивного знання, щоб зрозуміти, що саме робити з наданими посиланнями. Тільки люди можуть перейти на веб-сайт і зрозуміти поданий текст та посилання та діяти на ньому.

Тож у чому сенс виявлення, коли клієнтський код, який отримує доступ до таких відкритих URL-адрес, насправді не може нічого з цим зробити, якщо тільки розробник клієнта людини насправді не експериментує з представленими ресурсами? Це схоже на те саме, що визначити набір доступних функцій у посібнику з документації, просто з іншого напрямку та фактично залучаючи більше роботи для розробника. Чому цей другий підхід попереднього визначення того, що можна зробити в документі, що знаходиться поза реальними ресурсами REST, вважається неповноцінним?

Потреба у відкритті може бути нерелевантною, але посилання, що дозволяють виявити, служать більш цільним. На мою думку, найважливішим з них є те, що надання повного URI у відповідях клієнта означає, що жоден клієнт ніколи не потребуватиме "складання" URI. Це означає, що жоден клієнт ніколи не потребуватиме знань про структуру URI. А це, в свою чергу, дозволяє розробникам серверів змінювати схему URI, коли це їм підходить, оскільки їм не потрібно вважати, що старші клієнти все ще покладаються на старий спосіб структурування URI.

"Клієнти" можуть бути недостатньо просунуті, щоб користуватися нею, але користувачі клієнтів можуть. Зрештою, клієнт може бути таким же простим, як веб-браузер. Відкриття полягає в тому, щоб люди могли вивчати та використовувати API .

Наприклад, Дженкінс (сервер CI) має інтерфейс, схожий на REST. Перейдіть на будь-яку сторінку, розмістіть URL-адресу за допомогою "/ api", і ви отримаєте сторінку, що описує все, що ви можете зробити. Це робить навчання API тривіальним. Наприклад, http://ci.jruby.org доставить вас на сервер jenkins для jruby, а http://ci.jruby.org/api доставить вас до api для цієї конкретної сторінки.

Мені було приємно деякий час тому працювати з API, який мав документацію, яку було дуже, дуже важко зрозуміти.

Після того, як мені вдалося отримати фактичну відповідь від сервера, можна було порівняти документацію з відповіддю сервера і використати її для розшифровки документації (і так, розшифровка - це правильний термін). Проблема полягала в тому, що якщо на сервер буде надісланий запит, який був не зовсім коректний відповідно до специфікації, ви просто отримаєте помилку, а з нечитабельною документацією з'ясувати, як відправити правильні запити, було б майже неможливо. Існували також різні версії документації API, які не погоджувались між собою і, ймовірно, не погоджувались із самим API; це не допомогло.

Якби була одна команда, яку я міг би надіслати на сервер, повертаючи список усіх можливих команд і як саме їх надіслати, це було б дуже корисно. Виявлення не тільки для клієнтів, це також корисно для розробників програмного забезпечення.

ПРИМІТКА: Я не є експертом з цього питання, але я пройшов подібний процес, намагаючись узгодити різні нюанси інтерпретації людей "REST" кілька років тому. час.

Наскільки я розумію, це походить від гіпермедіа Роя Філдінга як двигуна стану програми, який називається "HATEOAS", який потім стає активізатором ідеї "семантичної павутини".

Отже ... в основному, і знову, наскільки я це розумію, ви робите свою заявку RESTful в основному самостійно описуючи таке, що споживачеві не потрібно попередньо знати офіційний договір, щоб споживати ваш вміст / функціональність. Вони можуть залучатись із деякої кінцевої кінцевої точки за замовчуванням, а потім переходити за контекстно-релевантними посиланнями, які надає ваша програма під час взаємодії споживача. Споживачем, звичайно, може бути людина або системний агент.

Якщо ви просто використовуєте "REST" для симпатичних URL-адрес, відображених на операціях CRUD, про які споживач повинен мати попередні знання та дзвінки відповідно до відомого договору, Рой Філдінг вважатиме це справді не ВДІЛЬНІМ.

Це не означає, що створена послуга RPC з ароматом REST не може бути корисною / вдосконаленням над більш досконалою моделлю RPC і підходить для обмеженого / контрольованого використання, але твердолюбиві поглянуть на неї і вважатимуть це виродженим / не дуже ВІДПОВІДНО.