Хотя может быть соблазнительно использовать собственную конечную точку для каждого типа или даже вводить специальные типы мультимедиа, которые определяют поддерживаемые поля, это может как-то привести к ситуациям, когда клиент ожидает, что ресурсы имеют определенный c тип, , которые они не , и, следовательно, тесно связаны со схемой, что может вызвать проблемы, если они изменятся позже, что в архитектуре REST может произойти в любое время.
Поскольку REST является де Фактически, это просто обобщение концепций, используемых в вебе с возможностью просмотра, в REST-архитектуре должны использоваться те же методы, которые могут и используются в Интернете.
Таким образом, одна из ваших основных целей всегда должна заключаться в том, чтобы сервер учит клиента о том, как добиться цели. Web делает это с помощью HTML форм , которые обучают клиента не только поддерживаемым и / или ожидаемым входным данным, но и целевому URI, на который отправляется запрос, операции HTTP, которую следует использовать. а также медиа-тип для отправки представления, который часто неявно задается application/x-www-form-urlencoded. Для JSON форматов представлений на основе hal-формы или ion могут быть полезны для достижения этой цели.
Формат представленного обмена должен быть как можно более обобщенным c но в том же отношении как можно более выразительным. Если вы посмотрите на HTML, то есть вы можете буквально express в ней что угодно, хотя, в конце концов, это просто веб-страница. Веб-страница с изображением предпочитаемой вами модели автомобиля или спортивной команды обрабатывается так же, как и любая другая веб-страница, и не намекает вашему веб-клиенту (браузеру) на то, что страница возвращает указанные c данные, представляющие автомобиль или спортивную команду, хотя человек способен распознать данные и связать с ними такие объекты.
Поскольку приложение (или компьютер в целом) вряд ли может самостоятельно вывести такие отношения, клиенту следует далее намекать на цель ресурс, особенно в отношении текущего состояния клиента. Здесь использование так называемых имен отношений ссылок является обязательным. Они более или менее представляют аннотации, сопровождающие URI, которые позволяют URI изменяться с течением времени без потери выразительности. Возможно, вы уже знакомы с именами отношений ссылок, такими как first, prev, self, next и last, которые в значительной степени говорят сами за себя в контексте подкачки страниц, хотя такие отношения ссылок могут использоваться чтобы намекнуть клиенту, что некоторый связанный ресурс, как ожидается, будет запрошен следующим через prefecth (вспомните страницу новостей, где на статью дается короткий тизер, а сервер может намекнуть клиенту, что полная статья, вероятно, будет запрошена следующей и как таковой клиент уже может загрузить статью в конец, поместить ее в кэш и позволить клиенту получать этот контент еще быстрее). Такие отношения ссылок, однако, не должны возникать из ниоткуда, поскольку в них можно буквально что-то поместить, и клиенты должны знать, что они express. Так как такие имена отношений ссылок должны быть стандартизированы , чтобы получить широкое распространение или, по крайней мере, следовать общепринятым методикам, определенным в Веб-ссылки , который назначает имена отношений ссылок в выделенное пространство имен, чтобы предотвратить конфликт имен.
В конце концов, как разработчик на стороне сервера, ваша основная цель - реализовать какой-то конечный автомат, или, как Jim Webber (2011) назвал его Domain Application Protocol, что клиент просто выполняет заказ, как при заказе в Amazon или в предпочитаемом вами интернет-магазине, где клиент в основном просто выполняет выбор, данный сервером, чтобы выполнить свою задачу покупки определенных товаров.