Я не розумію переваги HATEOAS для API, призначених для використання програмами (на відміну від людей, які безпосередньо переглядають ваш API). Звичайно, клієнт не прив’язаний до схеми URL-адрес, але він прив’язаний до схеми даних, яка є тим самим, що я думаю.
Наприклад, припустимо, що я хочу переглянути товар у замовлення, припустимо, я вже виявив URL-адресу замовлення чи знаю її вже.
HATEOAS:
order = get(orderURL);
item = get(order.itemURL[5]);
не HATEOAS:
order = get(orderURL);
item = get(getItemURL(order,5));
У першій моделі я повинен знати факт, що в об’єкта замовлення є поле itemURL. У другій моделі я повинен знати, як побудувати URL-адресу елемента. В обох випадках я мушу щось «знати» достроково, і що, власне, HATEOAS робить для мене?
Коли ви пишете клієнтську програму, ви повинні заздалегідь знати, що таке поле.
—
Темп
Ні, це головний момент HATEOAS, вам не потрібно знати заздалегідь, що таке поле, вам потрібно лише декілька встановлених стандартних балів, а решта можна знайти. "Принцип полягає в тому, що клієнт взаємодіє з мережевим додатком повністю за допомогою гіпермедіа, що динамічно забезпечується серверами прикладних програм. Клієнт REST не потребує попередніх знань про те, як взаємодіяти з будь-яким конкретним додатком або сервером за межами загального розуміння гіпермедіа".
—
Янніс
Як програма повинна отримувати товар із замовлення, якщо програма навіть не знає, що у замовлення є товар? Discovery працює для ручного перегляду, але не для автоматизованих програм.
—
Темп
Сам чоловік говорив про це тут: roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
—
Thiago Silva
get(orderURL);повинен вам сказатиthe fact that the order object has an itemURL field.