Хорошо, я тоже не эксперт по REST, в последнее время я много читаю по теме, так что я собираюсь написать не мой опыт или мнение, а скорее краткое изложение того, что я прочитал, особенно ОТДЫХ На практике книга.
Прежде всего, вы не можете избежать первоначального соглашения между клиентом и сервером, цель REST - заставить их договориться о самом минимуме вещей, которые имеют отношение к ним обоим, и позволить каждой стороне заботиться о свои собственные вещи сами. Например, клиент не должен заботиться о расположении ссылок или о том, как данные хранятся на сервере, а сервер не должен заботиться о состоянии клиента. То, о чем они заранее договариваются (т.е. до начала взаимодействия), - это то, что авторы вышеупомянутой книги называют «Протоколом доменного приложения» (DAP).
Важной особенностью DAP является то, что он является состоящим из состояний, хотя сам HTTP отсутствует (поскольку любое взаимодействие клиент-сервис имеет состояние, по крайней мере, начало и конец). Это состояние можно описать в терминах «Что клиент может / может / должен делать дальше»: «Я начал пользоваться сервисом, что теперь? Хорошо, я могу искать элементы. Искать этот элемент, что дальше? Хорошо Я могу заказать то и это ... и т. Д. "
Определение типа контента Hypermedia позволяет обрабатывать как обмен данными, так и состояние взаимодействия. Как я уже упоминал, состояние описывается в терминах возможных действий, и, как следует из «Ресурса» в REST, все действия описываются в терминах доступных ресурсов. Полагаю, вы видели аббревиатуру «HATEOAS» (гипермедиа как движок состояния приложения), так что это, по-видимому, означает.
Таким образом, для взаимодействия со службой клиент использует гипермедиа формат, который они оба понимают, который может быть стандартным, доморощенным или их комбинацией (например, на основе XML / XHTML). В дополнение к этому, они также должны совместно использовать протокол, который, скорее всего, HTTP, но поскольку некоторые детали не включены в стандарт, должны быть некоторые идиомы его использования, такие как «Использование POST для создания ресурса и PUT для обновления» , Кроме того, такой протокол будет включать точки входа службы (опять же, с точки зрения доступных ресурсов).
Эти три аспекта полностью определяют протокол домена. В частности, клиент не должен знать какие-либо внутренние ссылки до того, как он начнет использовать сервис, или запоминать их после завершения взаимодействия. В результате любые изменения во внутренней навигации, такие как переименование /cakes в /f5d96b5c, не затронут клиента, как только он соблюдает первоначальное соглашение и входит в магазин через парадную дверь.