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