Глаголы REST - какая конвенция “корректна”
Я хорошо в реализацию сервиса REST (на платформе Windows CE, если это имеет значение), и я начал использовать общие определения IBM использования POST для создания (ВСТАВЛЯЕТ) и ПОМЕЩЕННЫЙ для обновления.
Теперь я натыкался на определения Sun, которые являются точно противоположным. Таким образом, мой вопрос, который является "общепринятым" определением? Или есть ли даже один?
6 ответов
Недостатком использования PUT для создания ресурсов является то, что клиент должен предоставить уникальный идентификатор , который представляет объект, который он создает. Хотя обычно клиент может сгенерировать этот уникальный идентификатор, большинство разработчиков приложений предпочитают, чтобы их серверы (обычно через свои базы данных) создавали этот идентификатор. В большинстве случаев мы хотим, чтобы наш сервер контролировал создание идентификаторов ресурсов. Так что же нам делать? Мы можем переключить на использование POST вместо PUT.
Итак: Поместите = ОБНОВЛЕНИЕ
Сообщение = ВСТАВИТЬ
Здесь http://www.w3.org/Protocols/rfc2616/rfc2616.html - это официальное руководство по реализации поведение методов HTTP.
Причина использования POST как INSERT и PUT как UPDATE заключается в том, что POST является единственная неидемпотентная и небезопасная операция согласно HTTP. Идемпотентность означает, что независимо от того, сколько раз вы применяете операцию, результат всегда один и тот же. В SQL INSERT - единственная неидемпотентная операция, поэтому ее следует отображать на POST. UPDATE является идемпотентным, поэтому его можно сопоставить с PUT. Это означает, что одна и та же операция PUT / UPDATE может применяться более одного раза, но только сначала изменится состояние нашей системы / базы данных.
Таким образом, использование PUT для INSERT нарушит семантическое требование HTTP, согласно которому операция PUT должна быть идемпотентной.
Мы используем POST = Create, PUT = Update.
Почему? Нет веской причины. Нам нужно было выбрать одно, и это тот выбор, который я сделал.
Отредактируйте . Глядя на другие ответы, я понимаю, что решение может быть решено по ключевой проблеме создания.
Мы РАЗБИРАЕМ новые записи и возвращаем объект JSON со сгенерированным ключом. Похоже, это больше подходит для общепринятой семантики POST.
Мы помещаем в существующие записи полный URI, который идентифицирует объект.
Глаголы:
GET {path} : Получить ресурс с идентификатором {path} .
PUT {путь} : Создать или обновить ресурс с идентификатором {путь} .
УДАЛИТЬ {путь} : Удалить ресурс с идентификатором {путь} .
POST {путь} : Вызов действия, которое определяется как {путь} .
Когда намереваются создать новый ресурс, мы можем использовать PUT , если мы знаем, каким должен быть идентификатор ресурса, и мы можем использовать POST , если хотим, чтобы сервер для определения идентификатора нового ресурса.
PUT может использоваться для создания, когда сервер предоставляет клиенту контроль над частью своего пространства URI. Это эквивалентно созданию файла в файловой системе: когда вы сохраняете в файл, который еще не существует, вы создаете его, и если этот файл существует, результатом будет обновление.
Однако PUT лишен возможности неявного намерения клиента. Рассмотрим размещение заказа: если вы PUT на /orders/my-new-order, то смысл может быть только в обновлении ресурса, идентифицированного /orders/my-new-order, тогда как POST /orders/ может означать "разместить новый заказ", если принимающий POST ресурс имеет соответствующую семантику.
То есть, если вы хотите добиться чего-либо в качестве побочного эффекта создания нового ресурса, вы должны использовать POST.
Jan