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

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

RestWiki: минимальные методы

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

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


person Community    schedule 31.01.2010    source источник
comment
REST - это не протокол, это архитектурный стиль.   -  person occulus    schedule 31.01.2013


Ответы (2)


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

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

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

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

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

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

person Community    schedule 01.02.2010
comment
Создание ссылок на существительные в ваших URL-адресах - это не ограничение REST, а побуждение людей попасть в яму успеха. Это действительно говорит о многом - спасибо! - person ; 01.02.2010

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

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

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

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

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

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

Ознакомьтесь с этой статьей SO для получения дополнительной информации: Понимание REST: глаголы, коды ошибок и аутентификация

person Community    schedule 01.02.2010