примеры Non-HATEOAS

Question

Я смотрел в REST, в частности HATEOAS в Википедии, и утверждается, что

Принцип заключается в том, что клиент взаимодействует с сетевым приложением полностью через гипермедиа условии динамически серверами приложений

Как еще клиент будет взаимодействовать с приложением, если не через гипермедиа?

Каковы некоторые примеры использования взаимодействий, не связанных с HATEOAS?

Answer 1

API, не относящийся к HATEOAS, требует предварительного знания ресурсов и отношений между ними.

Например, если вы думаете об API-интерфейсе библиотеки, ресурс «книги» может иметь имя или идентификатор его автора в качестве атрибута. Чтобы получить дополнительную информацию об авторе, клиент API должен каким-то образом знать, что ресурс «автор» имеет конкретный контекстный путь и что его идентификатор является значением атрибута. Все становится еще сложнее, если клиент захочет заимствовать эту конкретную книгу. Для этого он должен знать, что необходимо выполнить POST-запрос, чтобы создать определенный ресурс с определенными атрибутами (например, идентификатор книги). Знание того, как делать такие вещи, должно быть жестко запрограммировано в реализации клиента. В HATEOAS каждая «книга» будет иметь ссылки на все связанные ресурсы, а также содержать информацию о действиях, связанных с этой книгой.

API-интерфейс клиентских споров PayPal может служить примером реального мира без API HATEOAS. Проверьте 'list disputes' part: он предоставляет список ресурсов с различными атрибутами. Затем см. the 'provide evidence' part. В нем говорится, что клиент может предоставить ресурс, связанный с спором. Это невозможно понять, просто следуя ссылкам в ресурсах API. Если это HATEOAS, тогда в ресурсе «спора» должна быть какая-то ссылка, которая передаст возможность добавления «доказательств» в каждый спор.Вы, как программист, должны прочитать документацию, чтобы знать, что «споры» могут иметь «доказательства».

Я действительно рекомендую this video как отличный учебный материал о том, что такое HATEOAS и как могут быть выражены отношения между ресурсами.

Answer 2

важная часть вам не хватает в

Отдыхают клиент не нуждается в предварительных знаний о том, как взаимодействовать с любым конкретного приложения или сервера за пределы общего понимания гипермедиа

Идея заключается в том, что, не зная, какие ресурсы доступны из вашего API, или как с ними взаимодействовать, клиент может использовать HATEOAS для динамического обнаружения ваших API-интерфейсов и взаимодействия с ними.

Например:

{ 
    "_links": { 
     "self": { "href": "/orders" }, 
     "next": { "href": "/orders?page=2" } 
    } 
} 

Из self я могу сделать вывод, что я в настоящее время /orders/и от next следующий набор ресурсов доступны в /orders?page=2.

Более того, он также говорит мне с данного ресурса, какие действия доступны для меня база на этом ресурсное состояние

т.е. в этом случае должна быть вторая страница заказов, в противном случае next не будет быть вариантом. (было бы в ответе)

Посмотрите на Hal Browser, что позволяет вам динамически перемещаться по API без каких-либо знаний об этом.