уникальные ключи нарушают неидемпотентность POST? - PullRequest
Новая
       33

уникальные ключи нарушают неидемпотентность POST?

0 голосов
/ 16 сентября 2018

Я много читаю об идемпотенте и неидемпотенте, и я думаю , что я ясно понимаю эту концепцию. Однако, хотя сценарий POST сбивает меня с толку.

POST всегда должен создавать новый ресурс. например:

  1. POST api/persons { Name: "John" } --> persons/1
  2. POST api/persons { Name: "Jack" } --> persons/2
  3. POST api/persons { Name: "Jack" } --> persons/3

теперь это очевидно, но, скажем, у человека есть идентификатор в качестве PK, а также SSN, который является уникальным ключом. В этом случае, если я отправлю два запроса POST с одним и тем же SSN, это не приведет к созданию двух новых ресурсов:

  1. POST api/persons { Name: "John", SSN: 123 } --> persons/1
  2. POST api/persons { Name: "Jack", SSN: 123 } --> error

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

Это нарушает стандарт неидемпотентности REST POST?

1 Ответ

0 голосов
/ 16 сентября 2018

POST всегда должен создавать новый ресурс.

Это заблуждение - вы можете использовать POST для других целей. Это намеренно очень общий характер.

Это нарушает стандарт неидемпотентности REST POST?

Нет, потому что POST не требуется , чтобы быть неидемпотентным.

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

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

Но существуют определенные ограничения по длине URI и, следовательно, ограничения по длине запроса. Если нам нужно поддерживать запросы, превышающие эти ограничения, наш единственный вариант - переместить параметры в тело запроса.

И стандартные «безопасные» методы HTTP не имеют четко определенной семантики для тела запроса.

Поэтому, чтобы обеспечить правильное поведение, мы используем POST, а не GET. Эффект на сервере все еще «по существу только для чтения», но универсальные компоненты, которые могут видеть только сообщения (а не нашу внешнюю документацию API), не будут знать, что сообщение безопасно, и будут не сможет выполнять оптимизации (кэширование, автоматическая повторная отправка, сканирование), которые будут доступны при использовании безопасных методов.

Другими словами, все, что мы делаем в HTTP, может быть сделано с помощью POST - то, что делают другие методы, - это позволяет нам разблокировать оптимизации в общих потребителях / наблюдателях сообщений.

На практике HTTP вообще не ограничивает реализацию - он описывает семантику. Вот Рой Филдинг , объясняющий в 2002 году:

HTTP не пытается требовать, чтобы результаты GET были безопасными. Для этого требуется, чтобы семантика операции была безопасной, и, следовательно, это ошибка реализации, а не интерфейса или пользователя этого интерфейса, если в результате произойдет что-либо, что приведет к потере имущества (денег, кстати, для этого определения считается собственностью).

POST не обещает быть идемпотентным, и, следовательно, клиенты обречены на неудачу, если они предполагают, что оно дает такое обещание.

...