Що HATEOAS пропонує для відкриття та роз'єднання, окрім здатності більш чи менш вільно змінювати структуру URL-адреси?


61

Останнім часом я читав про Hypermedia як двигун стану додатків (HATEOAS), обмеження, яке, як стверджується, робить веб-API "справді РЕСТЕВНІМ". Він зводиться до того, що в основному включає в себе посилання на кожну відповідь на можливі переходи, які ви можете зробити з поточного стану.

Дозвольте проілюструвати, на чому ґрунтується HATEOAS, і, будь-ласка, виправте мене, якщо я щось пропустив.

/
    GET: {
        "_links": {
            "child": [
                { "href": "http://myapi.com/articles", "title": "articles" }
            ]
        }
    }

/articles?contains=HATEOAS
    GET: {
        "_items": [
            { "uri": "http://myapi.com/articles/0", "title": "Why Should I Care About HATEOAS?" },
            { "uri": "http://myapi.com/articles/1", "title": "HATEOAS: Problem or Solution?" }
        ],
        "_links": {
            "self": { "href": "http://myapi.com/articles", "title": "articles" },
            "parent": { "href": "http://myapi.com/", "title": "home" }
        }
    }

    POST: {
        "title": "A New Article",
        "body": "Article body",
        "tags": [ "tag1", "tag2" ]
    }

/articles/0
    GET: {
        "title": "Why Should I Care About HATEOAS?",
        "body": "Blah blah blah"
        "tags": [ "REST", "HATEOAS" ],
        "_links": {
            "self": { "href": "http://myapi.com/articles/0", "title": "article" },
            "parent": { "href": "http://myapi.com/articles", "title": "articles" }
        }
    }

Стверджується, що HATEOAS надає дві основні переваги:

  1. Весь сервіс можна знайти, починаючи з кореневого URI, документація більше не потрібна.

  2. Клієнт відключається від сервера, який тепер може вільно змінювати структуру URI. Це виключає необхідність версій API.

Але на мій погляд, сервіс набагато більше, ніж його структура URI. Щоб ефективно використовувати його, вам також потрібно знати:

  • які параметри запиту ви можете використовувати та їх можливі значення
  • структура JSON / XML / будь-яких документів, які потрібно надіслати у ваших запитах POST / PATCH / тощо
  • структура відповіді, що надсилається сервером
  • можливі помилки, які можуть виникнути
  • ...

Виходячи з вищесказаного, HATEOAS вирішує лише невелику частку проблем виявлення та зв'язку. Вам все одно потрібно документувати вищевказані чотири аспекти, і клієнти все ще будуть сильно пов'язані з сервером через них. Щоб уникнути злому клієнтів, вам все-таки потрібно версію свого API.

Єдина перевага, яку він надає, це те, що ви можете змінити структуру URL-адреси більш-менш вільно (до речі, що сталося з принципом "Прохолодні URI не змінюються" ?). Чи правильно я розумію?

Відповіді:


46

Я думаю, ваші інстинкти багато в чому правильні; ці проголошені переваги насправді не так вже й великі, оскільки для будь-якого нетривіального веб-додатку клієнтам доведеться дбати про семантику того, що вони роблять, а також про синтаксис.

Але це не означає, що ви не повинні змушувати вашу заявку слідувати принципам HATEOAS!

Що насправді означає HATEOAS ? Це означає структурувати вашу програму так, щоб вона в принципі була схожа на веб-сайт і щоб усі операції, які ви могли б зробити, могли бути виявлені без завантаження якоїсь складної схеми. (Складні схеми WSDL можуть охопити все, але до того часу, коли вони це зробили, вони перевищили здатність практично кожного програміста коли-небудь зрозуміти, не кажучи вже про те, що писати! Ви можете розглянути HATEOAS як реакцію проти такої складності.)

HATEOAS не означає лише багаті посилання. Це означає використання механізмів помилок стандарту HTTP, щоб точно вказати, що пішло не так; вам не доведеться просто відповідати "waaah! ні ", і натомість може надати документ, що описує, що насправді було неправильним і що може зробити клієнт щодо цього. Це також означає підтримку таких речей, як запити OPTIONS (стандартний спосіб дозволяти клієнтам дізнатися, які методи HTTP вони можуть використовувати) та узгодження типу вмісту, щоб формат відповіді міг бути адаптований до форми, з якою клієнти можуть працювати. Це означає введення пояснювального тексту(або, швидше за все, посилання на нього), щоб клієнти могли шукати, як використовувати систему в нетривіальних випадках, якщо вони не знають; пояснювальний текст може бути зрозумілим для людини або може бути машиночитаним (і може бути таким же складним, як ви хочете). Нарешті, це означає, що клієнти не синтезують посилання (крім параметрів запиту); клієнти використовуватимуть посилання лише у тому випадку, якщо ви їм їм сказали.

Ви повинні задуматися про перегляд сайту користувачем (який може читати JSON або XML замість HTML, так трохи дивно) з великою пам'яттю для посилань та енциклопедичним знанням стандартів HTTP, але в іншому випадку не знаю, що робити робити.

І звичайно, ви можете використовувати узгодження типу вмісту для обслуговування клієнта HTML (5) / JS, який дозволить їм використовувати вашу програму, якщо це їх браузер готовий прийняти. Зрештою, якщо ваш RESTful API є корисним, то це має бути "банальним" для впровадження на ньому?


6

Справа в тому, що HATEOAS повинен поставити другий стовп, який визначає, що таке RESTful API: стандартизований тип медіа. Сам сказав Рой Філдінг

API REST повинен витратити майже всі свої описові зусилля для визначення типів (-ів) засобів масової інформації, які використовуються для представлення ресурсів ".

За допомогою стандартизованого типу медіа, який чітко визначає перехід, і гіпертексту для вказівки ресурсу один на одного, ви можете створити графік ресурсу, який може приймати будь-яку форму, не порушуючи жодного клієнта. Як і робота в Інтернеті, насправді: у вас є зв'язок між документом, а документ записаний у HTML, який визначає, як слід слідувати за цими посиланнями. <a href>- це GET, <form>GET або POST (і визначте шаблон URL-адреси, який слід використовувати у випадку GET), <link type="text/css">це GET ... і т. д. Ось як браузери можуть переміщуватися по довільній структурованій HTML-сторінці та в Інтернеті.

Все, що ви зробили

  • які параметри запиту ви можете використовувати та їх можливі значення
  • структура JSON / XML / будь-яких документів, які потрібно надіслати у ваших запитах POST / PATCH / тощо
  • структура відповіді, що надсилається сервером
  • можливі помилки, які можуть виникнути

Чи є пункти, на які слід звернутись за визначенням стандартизованого типу медіа . Звичайно, це набагато важче, і не те, про що більшість людей замислюється, коли визначають API "REST". Ви не можете просто взяти вас суб’єктами господарської діяльності та занести їх атрибути в документ JSON, щоб мати API RESTful.

Звичайно, те, що сталося, це те, що REST якимось чином розбавив, що означає «використовувати HTTP замість складного SOAPy». Просто використання HTTP та HyperText недостатньо, щоб бути RESTful, саме це більшість людей помиляється.

Не те, що це необхідно погано: REST приносить жертву продуктивності та простоті розвитку в обмін на довгострокову ремонтопридатність та еволюційність. Він був створений для великої інтеграції додатків для підприємств. Невеликий веб-API із жорстко зашифрованою структурою JSON може бути тим, що вам потрібно. Просто не називайте це REST, його спеціальним веб-API, нічого більше. І це не означає, що це смокче, це просто означає, що він не намагається слідувати обмеженню REST.

Подальше читання

Сподіваюся, це допоможе трохи уточнити :)


2

Є кілька форматів Hypermedia, які прагнуть надати більш багаті відповіді, які містять додаткову інформацію про те, які запити надсилати, і ніщо не заважає вам збагатити відповідь ще більшою інформацією.

Ось приклад сиренного документа:

{
  "class": [ "order" ],
  "properties": { 
      "orderNumber": 42, 
      "itemCount": 3,
      "status": "pending"
  },
  "entities": [
    {
      "class": [ "info", "customer" ],
      "rel": [ "http://x.io/rels/customer" ], 
      "properties": { 
        "customerId": "pj123",
        "name": "Peter Joseph"
      },
      "links": [
        { "rel": [ "self" ], "href": "http://api.x.io/customers/pj123" }
      ]
    }
  ],
  "actions": [
    {
      "name": "add-item",
      "title": "Add Item",
      "method": "POST",
      "href": "http://api.x.io/orders/42/items",
      "type": "application/x-www-form-urlencoded",
      "fields": [
        { "name": "orderNumber", "type": "hidden", "value": "42" },
        { "name": "productCode", "type": "text" },
        { "name": "quantity", "type": "number" }
      ]
    }
  ],
  "links": [
    { "rel": [ "self" ], "href": "http://api.x.io/orders/42" },
    { "rel": [ "previous" ], "href": "http://api.x.io/orders/41" },
    { "rel": [ "next" ], "href": "http://api.x.io/orders/43" }
  ]
}

Як бачите, інформація про те, як викликати зв’язок actions, надається у повідомленні, а потім, інтерпретуючи цю інформацію, клієнт стає більш стійким до змін.

Він стає особливо потужним, якщо rels - це URI, які можна шукати, а не з фіксованого словника.


0

Де ви читали, що "документація більше не потрібна" для послуг HATEAOS? Як ви кажете, вам ще потрібно документувати семантику посилань. Однак з HATEOAS вам не потрібно документувати, а значить, зберігати назавжди структуру більшості URI.

HATEOAS дозволяє виконавцю служби змінювати та масштабувати реалізацію значно та ефективно, не змінюючи невеликий набір URI, від яких залежить клієнт. Простіше зберегти невелику кількість вхідних точок незмінними, ніж великий набір. Отже, зменшення кількості публічних точок входу до сервісу та динамічне надання посилань на субресурси (HATEOAS) насправді підтримують "Cool URIs не змінюються" краще, ніж послуги, які не є HATEOAS.


Одне місце, де можна прочитати, що "документація більше не потрібна" - це дисертація Роя Філдінга, який придумав цей термін.
Мерітон - страйк

1
Я просто шукав дисертацію Філдінга про використання "документації" і не знайшов нічого подібного до твердження "документація більше не потрібна". Чи можете ви вказати, де в дисертації Філдінга ви знайшли цю претензію?
Джонатан Гідді

0

(HATEOAS) - обмеження, яке, як стверджується, робить веб-API "по-справжньому"

Єдине, що робить його справжнім API REST - це дотримання всіх обмежень, а не лише одного.

Але на мій погляд, сервіс набагато більше, ніж його структура URI. Щоб ефективно використовувати його, вам також потрібно знати: ...

Ось чому нам потрібні інші обмеження, повідомлення, що описується, тощо ...

Щоб уникнути злому клієнтів, вам все-таки потрібно версію свого API.

Незалежно від того, як ви намагаєтеся, вам потрібно буде версію свого API. У клієнті REST ви все ще повинні знати, як потрапити на сторінку, де ви хочете робити речі, які посилання слідкувати та які властивості потрібно збирати на основі словника RDF, що описує повідомлення. Якщо вам потрібно щось замінити або видалити з цього Vocab, він, ймовірно, зламає всіх ваших клієнтів, і вам знадобиться нова версія. Тому я думаю, що REST - це не те, що слід публікувати на початку (і з'ясувати модель, коли ви постійно змінюєте API), інакше у вас буде багато версій. Вам спочатку потрібна стабільна модель домену, на якій ви можете побудувати ...

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.