HTML Diff
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