Почему включение глагола действия в URI в реализации REST нарушает протокол?
============================================================================

Мне нужно понять, почему включение глаголов действия в URI нарушает протокол REST для синтаксиса URI? Когда я читаю следующую статью, я чувствую, что слишком много людей слишком много шумит о глаголах и что они должны делать больше шума по типам контента:

 [RestWiki: Минимальные методы](http://rest.blueoxen.net/cgi-bin/wiki.pl?MinimumMethods)

В идеальном мире клиентские браузеры будут поддерживать GET, POST, PUT и DELETE для запросов. Однако поддерживаются только GET и POST, что означает, что мы застреваем, пытаясь идентифицировать операции, которые должны быть PUT и DELETE, с помощью общих глаголов действия в URL-адресе, таких как просмотр, создание, редактирование и удаление.

Как это нарушает дух архитектурных принципов REST, и каков контрольный пробел, который вы испытываете, добавив что-то вроде "удалить" в свой URL вместо использования "удаления"?

 

Единственная действительная причина для руководства по URI - это поощрять правильное использование глаголов REST. Если запрос выполняет действие, соответствующее ожиданию клиента в соответствии со стандартами HTTP, то действительно не имеет значения, что содержит URL.

Именование URL-адресов на основе существительных делает естественным создание поведения, которое согласуется с намеченной целью GET, PUT, POST и DELETE.

Когда вы помещаете глаголы в URL-адрес, это может стать очень запутанным, потому что часто глагол http будет иметь противоречивое поведение по отношению к URL-адресу. Правила REST говорят, что вы должны уважать HTTP-глагол, но обычно URL-адрес более описательный, поэтому он может вводить в заблуждение.

 .i1a { width: 336px; height: 280px; }
 @media(min-width: 768px) { .i1a { width: 728px; height: 90px; } }
 @media(min-width: 992px) { .i1a { width: 360px; height: 300px; } }
 @media(min-width: 1083px) { .i1a { width: 728px; height: 90px; } }

 (adsbygoogle = window.adsbygoogle || []).push({});

Тот факт, что браузеры поддерживают только подмножество HTTP-глаголов, не очень уместен, потому что даже когда у вас есть полный доступ ко всем HTTP-глаголам, вам все равно нужно смоделировать другие глаголы, такие как печать, закрытие, отменить.

Вы абсолютно правы, что людям нужно больше ориентироваться на типы контента, чем на структуру URL, когда речь идет о реализациях REST.

Приведение ваших URL-адресов в имена существительных не является ограничением REST, это касается поощрения людей попасть в яму успеха.

 

REST - это не протокол, а стиль. Таким образом, вы можете делать все, что соответствует вашим требованиям.

HTTP-глаголы предпочтительнее, если это возможно, поскольку они являются частью протокола HTTP и как таковой стандарт. Он также позволяет использовать существующие уровни безопасности и кэширования на стандартном веб-сервере без необходимости писать какое-либо промежуточное программное обеспечение.

REST предполагает, что мы должны использовать HTTP, а не добавлять слои абстракции, такие как SOAP, RPC или CORBA. Добавление дополнительных глаголов или добавление их в URL-адрес можно рассматривать как облегченную абстракцию.

Однако, поскольку вы вначале упоминаете, что они не поддерживаются последовательно в браузерах или в некоторых версиях Flash. Поэтому может возникнуть необходимость разместить их в URL-адресе в реальном мире, если вы получаете доступ с клиентской стороны.

 .i2a { width: 336px; height: 280px; }
 @media(min-width: 768px) { .i2a { width: 728px; height: 90px; } }
 @media(min-width: 992px) { .i2a { width: 360px; height: 300px; } }
 @media(min-width: 1083px) { .i2a { width: 728px; height: 90px; } }

 (adsbygoogle = window.adsbygoogle || []).push({});

Вы должны внимательно изучить это, хотя могут возникнуть серьезные проблемы с безопасностью при выполнении DELETE/PUT по URL-адресу.

Я бы предположил, что глаголы GET POST PUT и DELETE подходят практически для любой необходимости. Вам не нужны никакие новые глаголы или коды ответов, поскольку они должны быть универсальными. Добавьте дополнительную информацию в данные запроса и ответа.

Ознакомьтесь с этой статьей SO для получения дополнительной информации:
[Понимание REST: глаголы, коды ошибок и аутентификация](/questions/13774/understanding-rest-verbs-error-codes-and-authentication)