Код ответа HTTP для POST, когда ресурс уже существует

842

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

Я определил API, чтобы клиенты могли создавать или изменять объекты с помощью PUT:

PUT /objects/{id} HTTP/1.1
...

{json representation of the object}

{Id} - это идентификатор объекта, поэтому он является частью Request-URI.

Теперь я также рассматриваю возможность разрешения клиентам создавать объект с помощью POST:

POST /objects/ HTTP/1.1
...

{json representation of the object, including ID}

Поскольку POST подразумевается как операция добавления, я не уверен, что делать, если объект уже существует. Должен ли я рассматривать запрос как запрос на изменение или я должен вернуть код ошибки (который)?

rest http http-status-codes

— vmj
источник

5

По состоянию на июнь 2016 года FB явно устанавливает 200 при регистрации, когда электронная почта существует

— Green

4

Github API возвращает 422 при попытке создать ресурс (team / repo) с именем, которое уже используется

— Ken

1

Это зависит от того, считаете ли вы существование объекта ошибкой или нет. Если вы обрабатываете добавление, 200 или 204 являются наиболее подходящими кодами ответа.

— Suncat2000

1059

Мое чувство является 409 Conflictнаиболее подходящим, однако, редко встречается в дикой природе, конечно:

Запрос не может быть выполнен из-за конфликта с текущим состоянием ресурса. Этот код разрешен только в ситуациях, когда ожидается, что пользователь сможет разрешить конфликт и повторно отправить запрос. Тело ответа ДОЛЖНО содержать достаточно информации, чтобы пользователь мог распознать источник конфликта. В идеале, объект ответа должен включать в себя достаточно информации, чтобы пользователь или пользовательский агент мог решить проблему; однако это может быть невозможно и не требуется.

Конфликты чаще всего возникают в ответ на запрос PUT. Например, если использовалось управление версиями, а объект PUT включал в себя изменения ресурса, которые конфликтуют с ресурсами, сделанными ранее (сторонним) запросом, сервер может использовать ответ 409, чтобы указать, что он не может выполнить запрос , В этом случае объект ответа, скорее всего, будет содержать список различий между двумя версиями в формате, определяемом типом содержимого ответа.

— Wrikken
источник

11

почему бы не пойти на 400 Bad Request? Для меня это выглядит как ошибка проверки (вы предоставляете неверную информацию с неверным идентификатором).

— Мануэль Алдана

314

400 => «Запрос не может быть понят сервером из-за неправильного синтаксиса» . И сервер прекрасно понимает, но не может выполнить из-за конфликта. В запросе и синтаксисе нет ничего плохого, только проблема с данными. 400 сразу заставит меня поверить, что весь механизм, который я использую, имеет недостатки, а не только данные.

— Wrikken

42

@ Wrikken Это больше не правильно. HTTP 400 был изменен в RFC 7231, чтобы означать, что «сервер не может или не будет обрабатывать запрос из-за чего-то, что воспринимается как ошибка клиента (например, синтаксис искаженного запроса, кадрирование недопустимого сообщения запроса или обманчивая маршрутизация запроса)». Я не говорю, что 400 - правильное использование в этом случае, но оно может быть правильным с новым определением 400.

— javajavajavajavajava

19

@javajavajavajavajava: тем не менее, повторяющиеся данные, на мой взгляд, не являются «ошибкой клиента», но это, конечно, на глаз смотрящего.

— Wrikken

21

Я возвращаюсь HTTP 409с Locationзаголовком, указывающим на существующий / конфликтующий ресурс.

— Гили

100

В соответствии с RFC 7231 , A 303 See Other МОЖЕТ использоваться Если результат обработки POST будет эквивалентно представлению существующего ресурса .

— Nullius
источник

4

На мой взгляд, это вполне может быть принятым ответом. Хотя «MAY» указывает на совершенно необязательный элемент, это единственный код ответа, предложенный официальной документацией RFC 7231 .

— Нандо

16

Это самый ОТЛИЧНЫЙ ответ.

— Сет

6

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

— Синастетик

11

Извините, я не одобряю это. HTTP 300 - это перенаправление, а перенаправление на другой объект, который, вероятно, имеет другие свойства, было бы очень обманчивым.

— Майкл Шепер

6

Тебе не нужно сожалеть. Однако, если представление эквивалентно существующему ресурсу, как оно может иметь разные свойства? И даже если это произойдет, как перенаправление будет вводить в заблуждение? ОП говорит: я не уверен, что делать, если объект уже там. На самом деле это «тот же» объект. Почему перенаправление вводит в заблуждение? Вы говорите о другом объекте, который в виду ОП явно не.

— Nullius

86

Лично я иду с расширением WebDAV 422 Unprocessable Entity.

Согласно RFC 4918

Код 422 Unprocessable Entityсостояния означает, что сервер понимает тип содержимого объекта запроса (следовательно, 415 Unsupported Media Typeкод состояния не подходит), а синтаксис объекта запроса является правильным (таким образом, 400 Bad Requestкод состояния не подходит), но не смог обработать содержащиеся в нем инструкции.

— Gareth
источник

19

Это интересная мысль, которая побудила меня наконец прочитать RFD WebDAV. Тем не менее, я думаю, что значение 422 состоит в том, что запрос и включенная сущность были синтаксически правильными, но семантически не имели смысла.

— vmj

4

Искаженный JSON не является синтаксически правильной сущностью, поэтому 422мне кажется странным ...

— Авенд

7

Я бы не пошел с этим. Из того же URL-адреса, на который есть ссылка в ответе: «Например, это условие ошибки может возникнуть, если тело XML-запроса содержит правильно сформированные (то есть синтаксически правильные), но семантически ошибочные XML-инструкции». Это реальное значение необработанного объекта, в отличие от случая, когда вы отправляете полностью допустимый объект запроса с допустимым синтаксисом И семантикой, но единственная проблема заключается в том, что он конфликтует с существующим объектом. Фактически, если семантика объекта запроса была недействительной, подобного существующего объекта вообще не должно быть.

— Укротитель Шлэш

1

Если добавить комментарий Tamer, если второй запрос будет первым, то он будет успешным, что невозможно, если это семантически правильно. Следовательно, правильная семантика здесь не применима.

— Хариш

4

@ Тамер Почему так? Команда «Пожалуйста, создайте объект xy» синтаксически верна. Это семантически правильно, только если возможно создать объект xy. Если объект xy уже существует, он больше не может быть создан, поэтому это семантическая ошибка.

— Хаген фон

48

Все дело в контексте , а также в том, кто отвечает за обработку дубликатов в запросах (сервер или клиент или оба)

Если сервер просто указывает дубликат , посмотрите на 4xx:

400 Bad Request - когда сервер не обработает запрос, потому что это явная ошибка клиента
409 Конфликт - если сервер не будет обрабатывать запрос, но причиной этого является не ошибка клиента
...

Для неявной обработки дубликатов, посмотрите на 2XX:

200 ОК
201 Создано
...

если сервер должен что-то вернуть , посмотрите на 3XX:

302 найдено
303 См. Другое
...

когда сервер может указать существующий ресурс, это подразумевает перенаправление.

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

— Славомир Ленарт
источник

2

Запрос не дублирует ресурс, он добавляет данные к одному. На мой взгляд, ваш лучший ответ из всех.

— Suncat2000

28

Возможно, в конце игры, но я столкнулся с этой проблемой семантики, пытаясь создать REST API.

Чтобы немного расширить ответ Вриккена, я думаю, что вы можете использовать любой из них 409 Conflictили в 403 Forbiddenзависимости от ситуации - вкратце, используйте ошибку 403, когда пользователь не может сделать абсолютно ничего для разрешения конфликта и завершения запроса (например, он не может отправить запрос). DELETEзапросить явное удаление ресурса) или использовать 409, если что-то может быть сделано.

10.4.4 403 Запрещено

Сервер понял запрос, но отказывается его выполнить. Авторизация не поможет и запрос НЕ ДОЛЖЕН повторяться. Если метод запроса не был HEAD и сервер желает сообщить, почему запрос не был выполнен, он ДОЛЖЕН описать причину отказа в объекте. Если сервер не желает предоставлять эту информацию клиенту, вместо него можно использовать код состояния 404 (не найден).

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

Что касается PUTvs. POST... POSTследует использовать для создания нового экземпляра ресурса, когда пользователь не имеет средств или не должен создавать идентификатор для ресурса. PUTиспользуется, когда идентификатор ресурса известен.

9,6 ставок

...

Принципиальное различие между запросами POST и PUT отражается в различном значении Request-URI. URI в запросе POST идентифицирует ресурс, который будет обрабатывать вложенный объект. Этот ресурс может быть процессом приема данных, шлюзом к другому протоколу или отдельным объектом, принимающим аннотации. Напротив, URI в запросе PUT идентифицирует объект, заключенный в запросе - пользовательский агент знает, для чего предназначен URI, и сервер НЕ ДОЛЖЕН пытаться применить запрос к какому-либо другому ресурсу. Если сервер желает, чтобы запрос был применен к другому URI,

он ДОЛЖЕН отправить ответ 301 (постоянно перемещен); Затем пользовательский агент МОЖЕТ принять собственное решение относительно того, следует ли перенаправить запрос.

— p0lar_bear
источник

7

Я думаю, что 403 Запрещено подразумевает, что, хотя пользователь аутентифицирован , он не авторизован для выполнения запрошенного действия. Я не использовал бы это для ошибок проверки. Пример : не авторизован, я пытаюсь что-то удалить. Сервер отправляет мне 401 Unauthorized (который просто плохо назван, должен быть 401 Unauthenticated ). Я вхожу и пытаюсь снова. На этот раз сервер проверяет мои разрешения, видит, что я не разрешен, и возвращает 403 Запрещено . Также посмотрите этот вопрос .

— Стейн де Витт

Хм ... правда. Мысль здесь прыгнула прямо к тому, чтобы сказать пользователю, что его полномочия делают ресурс неизменным в сценарии использования OP - он уже существует, у вас нет разрешения что-либо делать для разрешения конфликта, не пытайтесь снова создать ресурс.

— p0lar_bear

3

Согласно спецификации подразумевается, что ошибка 409 не может быть возвращена POSTзапросом (при правильном использовании), поскольку в нем говорится, что он должен быть возвращен, когда он конфликтует с целевым ресурсом . Поскольку целевой ресурс еще не был опубликован, он не может конфликтовать, и поэтому отвечать на 409 Conflictнего не имеет никакого смысла.

— Грант Гричан

1

Я бы не сделал вывод, что ошибка 409 не может быть возвращена POST, на самом деле, я бы сделал вывод об обратном, потому что «конфликты чаще всего возникают в ответ на запрос PUT». кажется, указывает, что другие методы запроса также могут использовать этот код. Кроме того, «тело ответа должно включать в себя достаточно информации, чтобы пользователь мог распознать источник конфликта. В идеале, объект ответа должен включать в себя достаточно информации, чтобы пользователь или пользовательский агент мог решить проблему; однако это может быть невозможно и не требуется . " ( webdav.org/specs/rfc2616.html#status.409 )

— JWAspin

14

«302 найдено» звучит логично для меня. И RFC 2616 говорит, что на него МОЖНО ответить на другие запросы, кроме GET и HEAD (и это, безусловно, включает POST)

Но он по-прежнему удерживает посетителя, переходящего по этому URL, чтобы получить этот ресурс «Найдено» в RFC. Чтобы перейти непосредственно к реальному «найденному» URL-адресу, нужно использовать «303 См. Другое», что имеет смысл, но заставляет другой вызов получить свой следующий URL-адрес. С хорошей стороны, этот GET кешируется.

Я думаю, что я бы использовал "303 см. Другие" . Я не знаю, смогу ли я ответить "вещью", найденной в теле, но я хотел бы сделать это, чтобы сохранить одну поездку на сервер.

ОБНОВЛЕНИЕ: после перечитывания RFC я все еще думаю, что несуществующий код " 4XX + 303 Found" должен быть правильным. Однако «Конфликт 409» - это лучший из существующих кодов ответов (как указано @Wrikken), возможно, включающий заголовок Location, указывающий на существующий ресурс.

— alanjds
источник

88

Статусы 3xx предназначены для перенаправления

— Aviram Netanel

1

«Запрашиваемый ресурс временно находится под другим URI». из w3.org/Protocols/rfc2616/rfc2616-sec10.html

— извещение о статуе

1

ИМХО, «307 Временное перенаправление» - это реальное временное перенаправление. «302» неоднозначно, но «НАЙДЕНО !!» это действительно желаемое сообщение здесь. Лучший однозначный компромисс - «303 See Other» в семантике HTTP. Я бы пошел с «303 See Other».

— alanjds

@DavidVartanian Hum ... я не вижу здесь ошибки. Клиент отправляет правильный запрос, но как сказать: «Извините, но то, что вы пытаетесь создать здесь, уже существует ТАМ»? Кажется, работа для некоторых 3xx. Это не 4xx для меня, так как нет ошибки клиента.

— alanjds

1

@DavidVartanian Спасибо за обсуждение. Обновил ответ до 409 . Клиент неправильно просит невозможного, даже если не знает, что это невозможно.

— alanjds

11

Я не думаю, что вы должны это делать.

Как вы знаете, POST изменяет коллекцию и используется для СОЗДАНИЯ нового элемента. Итак, если вы отправляете идентификатор (я думаю, что это не очень хорошая идея), вам следует изменить коллекцию, т. Е. Изменить элемент, но это сбивает с толку.

Используйте его, чтобы добавить элемент без идентификатора. Это лучшая практика.

Если вы хотите захватить УНИКАЛЬНОЕ ограничение (не идентификатор), вы можете ответить 409, как вы можете сделать в запросах PUT. Но не удостоверение личности.

— Альфонсо Тиенда
источник

Как насчет объекта, который имеет отношение таблицы соединения? Скажем, у нас есть account, product и account_product в виде таблиц базы данных. Я хочу добавить продукт в учетную запись, поэтому я бы хотел опубликовать в / account / {id} / product с product_id. Если разрешено только одно отношение аккаунта к продукту, что я должен вернуть?

— Парткил

2

Забудьте таблицы базы данных. Допустим, продукт может быть связан только с учетной записью ... Тогда это отношения один ко многим. Итак, POST / product / {id} с {'account': account_id}. Если у вас максимальная мощность равна 1 (отношение один к одному) .... Почему они отделяются от остальных объектов? Ошибка кардинальности составит всего 400 ошибок. Будь проще. Я надеюсь, что понял ваш вопрос.

— Альфонсо Тьенда

Я только что задал этот вопрос, и для меня идентификатором является не технический идентификатор в базе данных, а что-то вроде балансовой единицы. В этом приложении пользователь-менеджер может создавать компании и должен дать им код. Это идентификатор компании для пользователя, несмотря на то, что таблица БД также имеет технический идентификатор. Так что в моем случае я верну 409, если такая же балансовая единица уже существует.

— AlexCode

@partkyle Прекратите использовать PK в качестве публичных идентификаторов !!

— Синастетическая

Некоторые сущности имеют уникальные ограничения, а не только идентификатор. Как и учетная запись, вы не можете создать учетную запись, если пользователь не предоставил имя пользователя. А добавить учетную запись без имени пользователя, очевидно, невозможно

— rocketspacer

9

Я хотел бы пойти с 422 Unprocessable Entity, который используется, когда запрос является недействительным, но проблема не в синтаксисе или аутентификации.

В качестве аргумента против других ответов использование любого 4xxкода без ошибок подразумевает, что это не ошибка клиента, и это, очевидно, так. Использовать 4xxкод без ошибок для представления ошибки клиента просто не имеет никакого смысла.

Кажется, что 409 Conflict это самый распространенный ответ здесь, но, согласно спецификации, это означает, что ресурс уже существует, и новые данные, которые вы применяете к нему, несовместимы с его текущим состоянием. Если вы отправляетеPOSTзапросите, например, имя пользователя, которое уже занято, фактически не конфликтует с целевым ресурсом, поскольку целевой ресурс (ресурс, который вы пытаетесь создать) еще не был опубликован. Это ошибка специально для контроля версий, когда существует конфликт между версией хранимого ресурса и запрашиваемой версией ресурса. Это очень полезно для этой цели, например, когда клиент кэширует старую версию ресурса и отправляет запрос на основе этой неверной версии, которая больше не будет условно допустимой. «В этом случае представление ответа, вероятно, будет содержать информацию, полезную для объединения различий на основе истории изменений». Запрос на создание другого пользователя с таким именем просто не обрабатывается, не имеет никакого отношения к управлению версиями.

Напомним, что 422 также является кодом состояния, который GitHub использует, когда вы пытаетесь создать хранилище по имени, которое уже используется.

— Грант Гричан
источник

422 - спецификация webdav, поэтому я бы не советовал использовать это для REST API

— rwenz3l

7

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

РЕДАКТИРОВАТЬ: Стоит также отметить, что вы должны рассмотреть PUT, так как вы предоставляете ID. Тогда поведение простое: «Мне все равно, что там сейчас, положите эту вещь туда». То есть, если там ничего нет, оно будет создано; если что-то есть, оно будет заменено. Я думаю, что POST является более подходящим, когда сервер управляет этим ID. Разделение двух понятий в основном говорит вам, как с этим бороться (то есть PUT является идемпотентом, поэтому он должен всегда работать до тех пор, пока полезная нагрузка проверяется, POST всегда создает, поэтому, если есть коллизия идентификаторов, то 409 описывает этот конфликт) ,

— Sinaesthetic
источник

Согласно спецификации подразумевается, что ошибка 409 не может быть возвращена POSTзапросом (при правильном использовании), поскольку в нем говорится, что он должен быть возвращен, когда он конфликтует с целевым ресурсом . Поскольку целевой ресурс еще не был опубликован, он не может конфликтовать, и поэтому отвечать на 409 Conflictнего не имеет никакого смысла.

— Грант Гричан

Дискуссионный ИМО. Если вы публикуете в / users, то ресурс представляет собой коллекцию, а не отдельную запись / users / {id}

— Sinaesthetic

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

— Грант Гричан

Мне нравится ваше предложение, чтобы использовать PUTхотя.

— Грант Гричан

4

В конце концов, еще одно потенциальное лечение - использование PATCH. PATCH определяется как то, что изменяет внутреннее состояние и не ограничивается добавлением.

PATCH решит проблему, позволив вам обновить уже существующие элементы. См .: RFC 5789: PATCH

— Мартин Керстен
источник

2

Патч как PUT, но не полная замена. Он используется для изменения части ресурса, такой как добавление, удаление или изменение отдельного элемента ресурса вместо замены его целиком.

— Синастетическая

3

Почему не принят 202 ? Это нормальный запрос (200 с), клиентских ошибок (400 с) как таковых не было.

Из 10 определений кода состояния :

«202 Принято. Запрос принят к обработке, но обработка не завершена».

... потому что его не нужно было завершать, потому что он уже существовал. Клиент не знает, что он уже существует, он не сделал ничего плохого.

Я полагаюсь на 202 и возвращаю содержимое, похожее на то, /{resource}/{id}что вернул бы GET .

— Филипп Харрингтон
источник

21

Этот ответ неверен. 202 означает, что сервер не обнаружил проблему с запросом, но решил обработать запрос после ответа. Это также означает, что ожидается, что обработка будет успешной. В нашем случае сервер знает, что обработка не удастся, поэтому 202 - неправильный ответ.

— Адриан

4

Примером 202 может быть очередь или подписка. Другими словами, результат запроса может быть недоступен сразу, если вы запросите его прямо сейчас.

— Синастетическая

1

Это было бы целесообразно, если бы сервер все еще обрабатывал запрос. 200 или 204 будет более распространенным. Так как OP делает запрос на добавление, существование объекта является ожидаемым условием, а не ошибкой.

— Suncat2000

Нет смысла говорить клиенту, что запрос был принят, потому что вы уже знаете, что это не так!

— lucastamoios

1

@Adrian и lucastamoios Я думаю, вы оба предполагаете, что сервер синхронно читает из базы данных, прежде чем предоставить ответ. Это не всегда так, поэтому этот ответ не является «неправильным», поскольку сервер не всегда «знает» о существующей записи. Это в значительной степени имеет место в асинхронных системах, где уровень API просто записывает запросы на обработку фоновыми работниками.

— gsaslis

2

Наткнулся на этот вопрос при проверке правильности кода для дубликата записи.

Прошу прощения за мое невежество, но я не понимаю, почему все игнорируют код «300», который четко говорит «множественный выбор» или «неоднозначный»

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

https://tools.ietf.org/html/rfc7231#section-6.4.1

— Hitin
источник

Насколько я понимаю: «код состояния указывает, что целевой ресурс имеет более одного представления ... предоставляется информация об альтернативах, чтобы пользователь (или пользовательский агент) мог выбрать предпочтительное представление, перенаправив свой запрос одному или нескольким из них. идентификаторы "Мы явно пытаемся предотвратить более одного представления. Там нет вариантов. У клиента нет альтернативы на выбор. Клиент должен повторно отправить с другим идентификатором. С учетом вышесказанного следует также подумать о том, следует ли генерировать уникальные идентификаторы на клиенте и на сервере.

— musicin3d

Семантически, клиент говорит «Создать это», а сервер отвечает: «Идите сюда». Разговор не имеет никакого смысла. Это почти как если бы сервер говорил клиенту "вместо этого публиковать в этом месте". 300 больше подходят для ответа на запрос GET или POST в случае, когда сервер отвечает «Хорошо, я его создал, и все кончено» ..

— Sinaesthetic

2

Скорее это 400 Bad Request

6.5.1. ошибка 400, неверный запрос

Код состояния 400 (неверный запрос) указывает на то, что сервер не может или не будет обрабатывать запрос из-за чего-то, что воспринимается как ошибка клиента (например, синтаксис искаженного запроса, кадрирование неверного сообщения запроса или обманчивая маршрутизация запроса).

Поскольку запрос содержит повторяющееся значение (значение, которое уже существует), его можно воспринимать как ошибку клиента. Необходимо изменить запрос перед следующей попыткой.
Учитывая эти факты, мы можем сделать вывод, что HTTP STATUS 400 Bad Request.

— Мохаммед Сейфер
источник

1

Неверный запрос означает, что существует внутренняя проблема с синтаксисом пакета. Если в другом контексте (например, ресурс еще не существует), пакет будет успешным, то он не должен возвращать ошибку 400.

— Грант Гричан

1

Как насчет 208 - http://httpstatusdogs.com/208-already-reported ? Это вариант?

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

— Фернандо Феррейра
источник

Это не вариант, потому что вы хотите добавить определенный элемент, идентификатор которого уже существует. Итак, вы пытаетесь что-то добавить, но это уже есть. OK будет применяться только в том случае, если набор данных был увеличен. Добавить что-то -> Хорошо, я ничего не добавил. Не подходит, наверное.

— Мартин Керстен

Как я уже сказал, я не думаю, что это ошибка. Но я вижу смысл @martin

— Фернандо Феррейра

Если ресурс не был успешно создан, то по определению возникает ошибка.

— Грант Гричан,

POST также используется для добавления данных. Это по определению , а не ошибка .

— Suncat2000

@ Suncat2000 Даже если это так, если данные не были успешно добавлены, по-прежнему возникает ошибка. И если ресурс уже существует, данные не будут добавлены.

— Грант Гричан

0

В вашем случае вы можете использовать 409 Conflict

И если вы хотите проверить другие HTTPsкоды состояния из списка ниже

1 × × Информационный

100 Continue
101 Switching Protocols
102 Processing

2 × × Успех

200 OK
201 Created
202 Accepted
203 Non-authoritative Information
204 No Content
205 Reset Content
206 Partial Content
207 Multi-Status
208 Already Reported
226 IM Used

3 × × Перенаправление

300 Multiple Choices
301 Moved Permanently
302 Found
303 See Other
304 Not Modified
305 Use Proxy
307 Temporary Redirect
308 Permanent Redirect

4 × × Ошибка клиента

400 Bad Request
401 Unauthorized
402 Payment Required
403 Forbidden
404 Not Found
405 Method Not Allowed
406 Not Acceptable
407 Proxy Authentication Required
408 Request Timeout
409 Conflict
410 Gone
411 Length Required
412 Precondition Failed
413 Payload Too Large
414 Request-URI Too Long
415 Unsupported Media Type
416 Requested Range Not Satisfiable
417 Expectation Failed
418 I’m a teapot
421 Misdirected Request
422 Unprocessable Entity
423 Locked
424 Failed Dependency
426 Upgrade Required
428 Precondition Required
429 Too Many Requests
431 Request Header Fields Too Large
444 Connection Closed Without Response
451 Unavailable For Legal Reasons
499 Client Closed Request

5 × × Ошибка сервера

500 Internal Server Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
505 HTTP Version Not Supported
506 Variant Also Negotiates
507 Insufficient Storage
508 Loop Detected
510 Not Extended
511 Network Authentication Required
599 Network Connect Timeout Error

— Абд Абугхазалех
источник