0 added
0 removed
Original
2026-01-01
Modified
2026-03-10
1
<p>Теги: spring, java, rest-клиент, hypermedia as the engine of application state, hateoas, архитектурный принцип проектирования api, rest, get, self</p>
1
<p>Теги: spring, java, rest-клиент, hypermedia as the engine of application state, hateoas, архитектурный принцип проектирования api, rest, get, self</p>
2
<p>Рассмотрим специфичный архитектурный принцип проектирования API, набирающий популярность на данный момент, -<strong>HATEOAS</strong>(Hypermedia as the Engine of Application State).</p>
2
<p>Рассмотрим специфичный архитектурный принцип проектирования API, набирающий популярность на данный момент, -<strong>HATEOAS</strong>(Hypermedia as the Engine of Application State).</p>
3
<p>HATEOAS можно рассматривать как продолжение архитектурных принципов REST, а точнее, как некоторое его ограничение. Данный принцип встречается далеко не только в Java-приложениях, написанных со Spring, но и в PHP-приложениях, где HATEOAS является неотъемлемой частью некоторых фреймворков.</p>
3
<p>HATEOAS можно рассматривать как продолжение архитектурных принципов REST, а точнее, как некоторое его ограничение. Данный принцип встречается далеко не только в Java-приложениях, написанных со Spring, но и в PHP-приложениях, где HATEOAS является неотъемлемой частью некоторых фреймворков.</p>
4
<h2>Самым простым образом HATEOAS можно описать так:</h2>
4
<h2>Самым простым образом HATEOAS можно описать так:</h2>
5
<p><em>"Web-сервисы тоже люди и они тоже хотят ходить по ссылкам, как ходят настоящие люди по страницам, используя HTTP/HTML"</em></p>
5
<p><em>"Web-сервисы тоже люди и они тоже хотят ходить по ссылкам, как ходят настоящие люди по страницам, используя HTTP/HTML"</em></p>
6
<p>Т.е. своего рода гипертекст для<strong>REST-клиентов</strong>. Разберёмся подробнее. Если бы мы рассматривали классический веб-сервис работы, например, со студентами, то выглядел бы он примерно таким образом:</p>
6
<p>Т.е. своего рода гипертекст для<strong>REST-клиентов</strong>. Разберёмся подробнее. Если бы мы рассматривали классический веб-сервис работы, например, со студентами, то выглядел бы он примерно таким образом:</p>
7
GET /students/{id} - возвращает JSON конкретного студента PUT /students/{id}/transfer/{groupId} - перевод студента в другую группу и т.д. И GET-метод обычно возвращает что-то вроде: { "id": 5, "name": "Ivan Ivanov" }<p>Чтобы работать с данным веб-сервисом, нам необходимо помнить все URL данных методов. При этом, если какая-то операция недоступна по каким-то причинам (или по бизнес-логике, или с точки зрения прав доступа), мы узнаем об этом только тогда, когда обратимся по данному URL.</p>
7
GET /students/{id} - возвращает JSON конкретного студента PUT /students/{id}/transfer/{groupId} - перевод студента в другую группу и т.д. И GET-метод обычно возвращает что-то вроде: { "id": 5, "name": "Ivan Ivanov" }<p>Чтобы работать с данным веб-сервисом, нам необходимо помнить все URL данных методов. При этом, если какая-то операция недоступна по каким-то причинам (или по бизнес-логике, или с точки зрения прав доступа), мы узнаем об этом только тогда, когда обратимся по данному URL.</p>
8
<p>Разберёмся, что будет возвращать метод GET, написанный по принципу HATEOAS:</p>
8
<p>Разберёмся, что будет возвращать метод GET, написанный по принципу HATEOAS:</p>
9
{ "id": 5, "name": "Ivan Ivanov", "links": [{ "rel": "self", "href": "http://localhost/students/5" }, { "rel": "transfer", "href": "http://localhost/students/5/transfer" }], }<p>В данном примере, помимо данных объекта, возвращаются ещё и ссылки, причём с дополнительной информацией. REST-клиент, получив такой ответ, всегда теперь знает: - ссылку на данный объект (self); - операции, которые можно делать с данным объектом; - ссылки по которым эти операции доступны.</p>
9
{ "id": 5, "name": "Ivan Ivanov", "links": [{ "rel": "self", "href": "http://localhost/students/5" }, { "rel": "transfer", "href": "http://localhost/students/5/transfer" }], }<p>В данном примере, помимо данных объекта, возвращаются ещё и ссылки, причём с дополнительной информацией. REST-клиент, получив такой ответ, всегда теперь знает: - ссылку на данный объект (self); - операции, которые можно делать с данным объектом; - ссылки по которым эти операции доступны.</p>
10
<p>Сохранив данный объект со ссылками, REST-клиент может спокойно осуществить доступную операцию. Более того, клиенту не нужно обращаться к другим методам, чтобы понять, что они недоступны.</p>
10
<p>Сохранив данный объект со ссылками, REST-клиент может спокойно осуществить доступную операцию. Более того, клиенту не нужно обращаться к другим методам, чтобы понять, что они недоступны.</p>
11
<h2>Но самое главное, теперь можно спокойно менять API !</h2>
11
<h2>Но самое главное, теперь можно спокойно менять API !</h2>
12
<p>Действительно, клиенту теперь нет необходимости запоминать заранее методы, он их получит динамически при обращении к ресурсу. Это похоже на открытие страниц сайта - достаточно помнить только главную страницу и просто переходить по ссылке, а как устроен сайт, мы редко запоминаем.</p>
12
<p>Действительно, клиенту теперь нет необходимости запоминать заранее методы, он их получит динамически при обращении к ресурсу. Это похоже на открытие страниц сайта - достаточно помнить только главную страницу и просто переходить по ссылке, а как устроен сайт, мы редко запоминаем.</p>
13
<p>Конечно, проблема "запомнить URL ресурса" осталась, но это уже совсем другая история.</p>
13
<p>Конечно, проблема "запомнить URL ресурса" осталась, но это уже совсем другая история.</p>
14
<p><em>Остались вопросы? Напишите в комментариях!</em></p>
14
<p><em>Остались вопросы? Напишите в комментариях!</em></p>
15
15