Нужно ли указывать идентификатор ресурса в URL запросов PUT и PATCH? - PullRequest
Новая
       90

Нужно ли указывать идентификатор ресурса в URL запросов PUT и PATCH?

0 голосов
/ 22 апреля 2020

Должен ли PUT и PATCH URL содержать идентификатор или он может быть помещен в тело? 

PUT /person/UUID {"name": "Jimmy"}

ИЛИ 

PUT /person/{"UUID":1, "name": "Jimmy"}

(то же самое для PATCH)?

1 Ответ

0 голосов
/ 23 апреля 2020

Поскольку PUT определяется как Замена текущего документа, найденного в местоположении URI, на документ, предоставленный в полезной нагрузке , отправляющий запрос PUT на /person, вероятно, должен привести к удалению любого лицо, управляемое этой конкретной конечной точкой, в случае, если URI представляет собой совокупность лиц.

Как упоминалось в этой публикации , можно использовать URI без какого-либо специального идентификатора объекта, если это все контейнер назначения. Подумайте о буфере обмена, куда вы можете скопировать некоторые данные, чтобы потом извлечь их и вставить в другое место. В таком случае идентификатор неявно дается самим URI, так как после всех URI стоит уникальный идентификатор ресурса

Обратите внимание, что URI в целом идентифицирует ресурс и не обязательно подразумевает некоторая форма родительско-дочерней структуры. Клиент особенно не должен пытаться извлечь знания из URI вообще.

Относительно PATCH это зависит. Обычно следует использовать носитель, предназначенный для исправления, например JSON Patch или JSON Merge Patch .

Прежнее представление определяет определенные поля, в которых указано, что поле должно быть добавлено, удалено или заменено на указанное значение в нотации, подобной приведенной ниже: 

   PATCH /my/data HTTP/1.1
   Host: example.org
   Content-Length: 326
   Content-Type: application/json-patch+json
   If-Match: "abc123"

   [
     { "op": "test", "path": "/a/b/c", "value": "foo" },
     { "op": "remove", "path": "/a/b/c" },
     { "op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ] },
     { "op": "replace", "path": "/a/b/c", "value": 42 },
     { "op": "move", "from": "/a/b/c", "path": "/a/b/d" },
     { "op": "copy", "from": "/a/b/d", "path": "/a/b/e" }
   ]

JSON Слияние Патч однако работает по другому. Он определяет некоторые правила по умолчанию, которые инструктируют сервер о том, как применить изменения к целевому документу. Документ, подобный приведенному ниже, т.е. добавит или обновит поле a , чтобы впоследствии иметь значение z , а свойство f из c ' s объект должен быть удален. Все остальные оставшиеся свойства этого ресурса остаются без изменений. 

   PATCH /target HTTP/1.1
   Host: example.org
   Content-Type: application/merge-patch+json

   {
     "a":"z",
     "c": {
       "f": null
     }
   }

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

Кэширование в HTTP де-факто работает на URI ресурса. Любая небезопасная операция, выполняемая с этим URI, приводит к тому, что кэш делает недействительным сохраненное представление для этой цели. Т.е. если вы ранее вызывали GET /person/1 и теперь выполняете PUT или PATCH, которые оба являются небезопасными операциями, на /person данные могут обновляться, хотя клиент, запрашивающий GET /person/1, впоследствии может по-прежнему получать кэшированный ответ через кеш, поскольку он не знает о каких-либо изменениях, внесенных в этот ресурс.

...