HATEOAS (Hypermedia as the Engine of Application State)

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

С учетом того, что REST API почти всегда делают на базе веб-решений, это требования выполняется по дефолту. Тут надо вспомнить, что REST появился как архитектурный стиль в то время, когда про WEB 2.0 еще толком никто не знал.

Со временем веб-архитектура развилась так, что сейчас "все есть веб". Поэтому у многих возникает вопрос, а где там HATEOAS? Появляются разные интерпретации и надуманные требования о содержимом ответов, которые должны давать REST API (например, что они обязательно должны содержать ссылки на другие ресурсы)

На самом деле в мире где еще не было WEB 2.0 HATEOAS означал лишь то, что REST приложение должно работать не с каким-то специфичным клиентом, который реализует свой протокол, а с любым приложением которое умеет работать с гипермедиа, т.е. по сути любые веб-клиенты.

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

Есть еще дополнительное требование, что все что вы можете сделать со стейтом REST приложения должно быть основано на результатах, полученных из предыдущих запросов. Это требования почти всегда выполняется - сначала запрашивается список ресурсов, потом из этого списка берется идентификтор конкретного ресурса и работ идет с ним.

Не надо придумывать новые смыслы для HATEOAS, данное требование жестко "зашито" в веб-архитектуру. Если вы используете веб-решение, то значит вы используете HATEOAS.