Подтвердить что ты не робот

HTTP MODIFY глагол для REST?

Насколько я вижу, нет способа RESTful применить модификацию к ресурсу. Чтобы сделать это, вы должны ПОЗЫВАТЬ ресурс в целом, перезаписав предыдущее представление. Я думаю, что это источник проблем, особенно когда ресурс имеет большое представление.

Я считаю, что это намекает на отсутствие глагола в HTTP1.1: что-то вроде MODIFY или PATCH. Даже WebDAV не имеет этого глагола (у него есть PROPPATCH, концепция которого аналогична, но не для ресурсов).

Разве текущий HTTP 1.1 набор глаголов слишком ограничен для реального мира RESTing?

Изменить. Я нашел предложение в IETF о глаголе PATCH

http://tools.ietf.org/html/draft-dusseault-http-patch-15

Эта спецификация определяет новую Метод HTTP/1.1 [RFC2616] PATCH который используется для частичного изменения ресурса.

Новый метод необходим для улучшить совместимость и предотвратить ошибки. Метод PUT уже для перезаписывания ресурса с совершенно новым телом, и не может быть повторно использован для частичных изменений. В противном случае прокси и кеши и даже клиенты и серверы могут получить путают относительно результата операция. PATCH упоминается в более ранних спецификаций HTTP, но не полностью определен.

Насколько я вижу, единственной проблемой такого глагола является отсутствие идемпотентности.

Изменить: По состоянию на март 2010 года существует RFC 5789 (метод PATCH для HTTP).

4b9b3361

Ответ 1

Существует веская причина, по которой нет такого глагола. Это почти невозможно обойти. Подумайте о 100 клиентах, модифицирующих один и тот же ресурс таким образом, как вы узнаете, где заканчивается ваша модификация? Что, если порядок имеет значение, и ваш "патч" фактически добавляется после другого "патча", и теперь то, что вы хотели добавить, на самом деле не было добавлено. Использование PUT с заголовками ETag является гораздо более разумным подходом к модификации ресурса, а затем пытается совместить несколько новых глаголов с неизвестными результатами. Наличие на самом деле ПОЛУЧИТЬ ресурс - это небольшая цена для оплаты повторяющихся результатов.

Ответ 2

Вы можете разделить ресурс на индивидуально обновляемые субресурсы.

например. у вас есть ресурс /user, представляющий информацию учетной записи пользователя, которую вы можете создать под-ресурсом /пользователь/адрес электронной почты, а затем выполните PUT для обновления только электронной почты.

Ответ 3

Вы можете использовать POST для частичных обновлений. Это не идеально, но это довольно RESTful.

Ответ 4

Я бы хотел, чтобы были стандартные и поддерживаемые глаголы вроде...

  • НАЙТИ, ПОИСК или ВОПРОС - так что он очищает запрос не для ресурса, а местоположения других ресурсов. Может быть, только ограниченная полезность.
  • MOVE, COPY, LINK - просто чертовски удобно, они будут действовать аналогично инструментам командной строки.
  • DISCOVER, MAP, INDEX или SITEMAP - чтобы вы могли получить макет ресурсов, аналогичный по идее файлу wsdl, или xmlrpc system.listMethods.
  • BEGIN, ACQUIRE или LOCK, а также COMMIT, END, DONE или RELEASE - чтобы это стало ясно, когда вы начинаете и заканчиваете транзакции или используете промежуточные ресурсы.
  • MODIFY, UPDATE, PATCH - потому что мы все хотим этого