Глаголы REST - какое соглашение является "правильным"

Ответ 1

Недостатком использования PUT для создания ресурсов является то, что клиент должен предоставить уникальный идентификатор, который представляет объект, который он создает. Хотя это обычно возможно для клиента для генерации этого уникального идентификатора большинство дизайнеров приложений предпочитают, чтобы их серверы (обычно через свои базы данных) создайте этот идентификатор. В большинстве случаев мы хотим наш сервер для управления генерации идентификаторов ресурсов. Так что же нам делать? Мы можем переключить для использования POST вместо PUT.

Итак: Put = UPDATE

Post = INSERT

Ответ 2

Причина использования POST как INSERT и PUT как UPDATE заключается в том, что POST является единственным nonidempotent и небезопасной операцией в соответствии с HTTP. Idempotent означает, что независимо от того, сколько раз вы применяете операцию, результат всегда один и тот же. В SQL INSERT - единственная неидентичная операция, поэтому она должна отображаться на POST. UPDATE является idempotent, поэтому его можно отобразить на PUT. Это означает, что одна и та же операция PUT/UPDATE может применяться более одного раза, но только сначала изменит состояние нашей системы/базы данных.

Таким образом, использование PUT для INSERT нарушит семантику HTTP, а именно требование о том, что операция PUT должна быть идемпотентной.

Ответ 3

Глаголы:

GET {path}: Получить ресурс с идентификатором {path}.

PUT {path}: создать или обновить ресурс с идентификатором {path}.

DELETE {path}: удалить ресурс с идентификатором {path}.

POST {path}: вызывать действие, которое идентифицируется {path}.

Когда мы намерены создать новый ресурс, мы можем использовать PUT, если мы знаем, каким должен быть идентификатор ресурса, и мы можем использовать POST, если мы хотим, чтобы сервер определял идентификатор нового ресурс.

Ответ 4

PUT может использоваться для создания, когда сервер предоставляет клиенту контроль над частью своего пространства URI. Это эквивалентно созданию файла в файловой системе: при сохранении файла, который еще не существует, вы создаете его, и если этот файл существует, результатом будет обновление.

Однако PUT не обладает способностью подразумеваемого намерения клиента. Рассмотрите возможность размещения заказа: если вы нажмете на/заказы/мой новый порядок, значение может только обновлять ресурс, идентифицированный /orders/my -new-order, тогда как POST/orders/может означать "разместить новый заказ", если ресурс приема POST имеет соответствующую семантику.

IOW, если вы хотите достичь чего-либо как побочного эффекта создания нового ресурса, вы должны использовать POST.

Jan

Ответ 5

Мы используем POST = Create, PUT = Обновить.

Почему? Нет веской причины. Мы должны были выбрать один, и этот выбор я сделал.

Edit. Рассматривая другие ответы, я понимаю, что проблема с созданием ключа может принять решение.

Мы открываем новые записи и возвращаем объект JSON сгенерированным ключом. Похоже, что это лучше подходит для общепринятой семантики POST.

Мы размещаем существующие записи с полным URI, который идентифицирует объект.

Ответ 6

Здесь http://www.w3.org/Protocols/rfc2616/rfc2616.html является официальным руководством по реализации поведения методов HTTP.

Ответ 7

Я изучаю концепции и реализации REST много в последнее время, и общий консенсус выглядит следующим образом: PUT используется для создания/обновления в зависимости от того, существует или нет ресурс. POST используется для добавления ресурса в коллекцию.

См. определения метода HTTP/1.1 http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

POST предназначен для обеспечения единообразного метода для покрытия следующих Функции:

  - Annotation of existing resources;

  - Posting a message to a bulletin board, newsgroup, mailing
    list, or similar group of articles;

  - Providing a block of data, such as the result of submitting a
    form, to a data-handling process;

  - Extending a database through an append operation.

Метод PUT запрашивает, чтобы закрытый объект был сохранен под предоставленный Request-URI. Если Request-URI ссылается на уже существующее ресурс, закрытый объект СЛЕДУЕТ считаться измененным версию той, которая находится на сервере происхождения.

Также см. принятый ответ на вопрос в Понимание REST: глаголы, коды ошибок и аутентификация.