Ну, REST - это просто обобщение концепций, которые уже много лет используются в браузерной сети.При последовательном применении этих концепций в ваших приложениях вы получите свободу для развития серверной части, одновременно получая устойчивость к изменениям на стороне клиента.Однако, чтобы воспользоваться такими сильными свойствами, необходимо соблюдать определенное количество ограничений, таких как соблюдение правил базового транспортного протокола или использование HATEOAS для дальнейшего управления состоянием приложения.Любая внеполосная информация, необходимая для взаимодействия со службой, приведет к связыванию и, следовательно, может либо сломать клиентов, либо предотвратить изменение серверов в будущем.
Распространенным заблуждением в архитектуре архитектуры REST является то, чтоURI должны быть осмысленными и выражать семантику для клиента.Однако в архитектуре REST URI - это просто указатель на ресурс, который клиент никогда не должен анализировать.Решение о том, следует ли вызывать URI, должно приниматься на основе сопутствующего имени отношения ссылки, которое может быть дополнительно описано в типе носителя или в общих стандартах.Т.е. в отношении ссылки на коллекцию с возможностью просмотра страниц, например prev, next, first или last, клиент может выбрать просмотр коллекции.Поэтому фактическая структура URI вообще не важна для REST.Слишком спроектированные URI могут привести к типизированным ресурсам .Поэтому мне не нравится термин restful-url на самом деле.Как тогда выглядят non-restful-url?
Хотя отправка всего через POST запросов технически является допустимой опцией, она также имеет некоторые недостатки, которые следует учитывать.IANA ведет список доступных HTTP-методов , которые вы можете использовать.Каждый метод передает разные обещания и семантику.Т.е. клиент, запускающий операцию GET на сервере, должен быть безопасным, предполагая, что вызов ресурса не вызывает каких-либо изменений состояния (безопасно), и в случае проблем с сетью запрос может быть повторно выполнен без каких-либо дополнительных соображений (идемпотент).Это очень важные преимущества для веб-сканеров.Кроме того, промежуточные узлы могут определять на основе метода запроса и полученного ответа, может ли ответ кэшироваться или нет.Хотя это не обязательно является проблемой с точки зрения отделения клиентов от серверов, это помогает убрать ненужную рабочую нагрузку с самого сервера, особенно когда состояние ресурса изменяется, улучшая масштабируемость всей системы.
POST, с другой стороны, не передает такие свойства.При отправке запроса POST на получение данных клиент не может быть уверен, действительно ли запрос приводит к изменениям состояния ресурсов или нет.При возникновении проблемы с сетью запрос мог достигнуть сервера и, возможно, создать новый ресурс, хотя ответ был просто потерян в середине пути, что могло бы держать клиента в состоянии неопределенности, может ли он просто повторно отправить запрос или нет.Кроме того, ответы для операций POST по умолчанию не кэшируются, только после явного добавления к ним информации о свободе.Вызов метода POST запрашивает целевой ресурс для обработки предоставленного представления в соответствии с собственной семантикой ресурсов.Поскольку буквально все что угодно может быть отправлено на сервер, важно, чтобы сервер обучал клиента тому, как должен выглядеть запрос.В HTML, т. Е. Это делается с помощью веб-форм, где пользователь может заполнить данные в определенных полях ввода и затем отправить данные на сервер, нажав кнопку отправки.Та же концепция может быть применена и для мобильных или REST-приложений.В этом вам может помочь повторное использование HTML-форм или определение собственной application/vnd.company-x.forms+json, где описание этого типа носителя публикуется (или регистрируется в IANA).
Фактический вопрос о том, куда включать определенные данные, к сожалению, является общим, чтобы дать краткий ответ.Кроме того, это зависит от того, должны ли данные быть общими или иметь какие-то проблемы с безопасностью.Хотя параметры могут передаваться на сервер через параметры URL (запрос, матрица, путь) до определенной степени , это, вероятно, не лучший вариант в общем случае, хотя параметры запроса шифруются во взаимодействиях SSL .Эта опция, тем не менее, удобна, если URI должен быть вставляемым без потери информации.Тогда это, конечно, не должно содержать данных, связанных с безопасностью.Информация, связанная с безопасностью, почти всегда должна передаваться в заголовках HTTP или, по крайней мере, в самой полезной нагрузке.
Обычно вы должны различать контент и метаданные, описывающие контент.В то время как контент должен быть фактической полезной нагрузкой запроса / ответа, любые метаданные, описывающие контент, должны идти внутри заголовков.Подумайте об изображении, которое вы хотите передать.Поскольку вы не хотите связываться с байтами изображения, вы просто добавляете имя изображения, формат сжатия и другие свойства, описывающие, как преобразовать байты обратно в представление изображения в заголовках.Эта дискриминация, вероятно, лучше всего подходит для стандартизированных форматов представления, поскольку вы должны быть в пределах возможностей спецификации, чтобы гарантировать совместимость.Тем не менее, даже там все может стать нечетким.То есть в области EDI существует пара четко определенных стандартов, таких как Edifact, Tradacoms и т. Д., Которые можно использовать для обмена различными форматами сообщений, такими как счета, заказы, ответы на заказы ... хотя разные системы ERP говорят на разных сленгахи вот тут все начинает усложняться и запутываться.
Если вы управляете своим форматом представления, поскольку вы, вероятно, не стандартизировали его или определили его лишь расплывчато, но все еще может быть сложнее определить, следует ли ставитьон просматривает ваш документ или добавляет его через заголовки.Здесь все зависит только от вашего дизайна.Я также видел представления, которые определяли собственные разделы заголовка в полезной нагрузке и поэтому воссоздали SOAP-подобную структуру envelop-header-body.