В годы, когда я определял и проектировал REST API, я все чаще обнаруживал, что это очень похоже на разработку веб-сайта, где путешествие пользователя, действия и ссылки раскадрованы и имеют решающее значение для UX.
В настоящее время с моими проектами API я возвращаю ссылки в элементах и в нижней части ресурсов. Они выполняют действия, изменяют состояние или возвращают другие ресурсы.
Но это как если бы каждая ссылка открывалась в новой вкладке; клиент исследует новый маршрут, и его следующие варианты могут сузиться по мере продвижения.
Если бы это был веб-сайт, это не обязательно был бы хороший дизайн. Пользователю придется либо открывать ссылки в новых вкладках, либо постоянно создавать резервные копии стека, чтобы добиться цели.
Хорошие сайты работают только вперед или действительно имеют способ указать ответвление от основного потока, то есть ссылки, автоматически открывающиеся в новых окнах (через тег привязки target).
Так должен ли хороший REST API быть спроектирован так, как будто клиент отбрасывает текущий ресурс и переходит к следующему и всегда продвигается вперед?
Или мы предполагаем, что клиент строит карту по ходу дела, как Roomba, исследующий нашу гостиную?
Суть концепции карты в том, что знание, которое следует вернуться к предыдущему ресурсу, из многих, о которых он может знать, находится в разумном человеке, в догадке. Компьютеры не способны угадывать, поэтому им нужно программирование, а это подразумевает внеплановую статическую документацию и нарушает REST.
