Код відповіді HTTP для POST, коли ресурс уже існує

842

Я будую сервер, який дозволяє клієнтам зберігати об’єкти. Ці об'єкти повністю побудовані на стороні клієнта, а також ідентифікатори об'єкта, які є постійними протягом усього терміну експлуатації об'єкта.

Я визначив API, щоб клієнти могли створювати або змінювати об'єкти за допомогою PUT:

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

{json representation of the object}

{Id} - ідентифікатор об'єкта, тому він є частиною URI-запиту.

Тепер я також розглядаю можливість дозволити клієнтам створити об'єкт за допомогою POST:

POST /objects/ HTTP/1.1
...

{json representation of the object, including ID}

Оскільки POST позначається як операція "додавання", я не впевнений, що робити у випадку, якщо об'єкт вже є. Чи повинен я ставитись до запиту як до запиту на модифікацію чи повинен повернути якийсь код помилки (який)?

rest http http-status-codes

— vmj
джерело

5

Станом на червень 2016 року ФБ нахабно встановлює 200 при реєстрації, коли існує електронна пошта

— Зелений

4

API Github повертає 422 при спробі створити ресурс (team / repo) з іменем, яке вже використовується

— Ken

1

Це залежить, чи вважаєте ви існування об'єкта помилкою чи ні. Якщо ви обробляєте додаток, 200 або 204 є найбільш підходящими кодами відповідей.

— Suncat2000

1055

Моє почуття є 409 Conflictнайбільш підходящим, проте, рідко, звичайно, це спостерігається:

Запит не вдалося виконати через конфлікт із поточним станом ресурсу. Цей код дозволений лише в тих випадках, коли очікується, що користувач зможе вирішити конфлікт і подати повторно запит. Орган реагування ДОЛЖЕН би включити достатньо інформації, щоб користувач міг розпізнати джерело конфлікту. В ідеалі суб'єкт відповіді повинен містити достатню кількість інформації для користувача або агента користувача, щоб вирішити проблему; однак це може бути неможливим і не потрібно.

Конфлікти, швидше за все, виникають у відповідь на запит PUT. Наприклад, якщо використовувались версії і сутність PUT включала зміни до ресурсу, які суперечать тим, які були зроблені попереднім (стороннім) запитом, сервер може використовувати відповідь 409, щоб вказати, що він не може виконати запит . У цьому випадку суб'єкт відповіді, ймовірно, міститиме список відмінностей між двома версіями у форматі, визначеному відповіддю Content-Type.

— Wrikken
джерело

11

чому б не піти на 400 поганих запитів? Для мене це схоже на помилку перевірки (ви надаєте неправильну корисну навантаження з незаконним ідентифікатором).

— мануель альдана

314

400 => "Запит не зміг зрозуміти сервер через неправильно сформований синтаксис" . І сервер чудово розуміє, але не в змозі виконати їх через конфлікт. Немає нічого поганого в запиті та синтаксисі, лише проблема з даними. 400 моментально змусить мене повірити, що весь механізм, який я використовую, хибний, а не лише дані.

— Wrikken

42

@Wrikken Це більше не вірно. HTTP 400 було змінено в RFC 7231 і означало, що "сервер не може або не обробляє запит через те, що сприймається як помилка клієнта (наприклад, синтаксис неправильного запиту, неправильне обрамлення повідомлення запиту або оманливе маршрутизація запиту"). Я не кажу, що в цьому випадку 400 є правильним, але це може бути правильним з новим визначенням 400.

— javajavajavajaвава

19

@javajavajaваяваява: все-таки дублюючі дані - це не «помилка клієнта» на моєму розумі, але це очевидно для очевидців.

— Вріккен

21

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

— Гілі

100

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

— Нулліус
джерело

4

На мою думку, це може бути прийнятою відповіддю. Хоча "МОЖЕ" вказує на абсолютно необов'язковий елемент, це єдиний код відповіді, запропонований офіційною документацією RFC 7231 .

— Нандо

16

Це найстрашніша відповідь.

— Сет

6

Я думаю, що контекст важливий. Наприклад: повернення 303 означає перенаправлення на знайдений ресурс. Це може мати сенс для виклику сервера на сервер, але якщо ви працювали через процес реєстрації користувача, це не мало б сенсу.

— Синестетик

11

Вибачте, я забороняю це. HTTP 300 стосується переадресації, і перенаправлення на інший об'єкт, який, ймовірно, має інші властивості, було б дуже оманливим.

— Майкл Шепер

6

Не треба шкодувати. Однак якщо представлення еквівалентно існуючому ресурсу, то як воно може мати різні властивості? І навіть якби це було, як би перенаправлення вводило в оману? ОП каже: Я не впевнений, що робити у випадку, якщо об’єкт вже є. Насправді це той самий об’єкт. Чому переспрямування буде вводити в оману? Ви говорите про інший об'єкт, який на думку ОП явно не відповідає.

— Нуллій

86

Особисто я йду з розширенням WebDAV 422 Unprocessable Entity.

За даними RFC 4918

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

— Гарет
джерело

19

Це цікава думка, і спонукало мене нарешті прочитати RFD WebDAV. Однак я думаю, що сенс 422 полягає в тому, що запит і включена сутність були синтаксично правильними, але семантично не мали сенсу.

— vmj

4

Неправильний JSON не є синтаксично правильним утворенням, тому 422вражає мене як дивно ...

— awendt

7

Я б з цим не пішов. З тієї ж URL-адреси, на яку посилається у відповіді: "Наприклад, ця умова помилки може виникнути, якщо тіло запиту XML містить добре сформовані (тобто синтаксично правильні), але семантично помилкові інструкції XML." Це справжнє значення не оброблюваної сутності, на відміну від випадків, коли ви надсилаєте цілком дійсний запит із дійсним синтаксисом І семантикою, але єдина проблема полягає в тому, що він конфліктує з існуючим об'єктом. Власне, якщо семантика суб'єкта запиту не була дійсною, взагалі не повинно бути подібного, існуючого.

— Тамер Шлаш

1

Додаючи до коментаря Тамера, якщо другий запит прийшов першим, то він би досяг успіху, що не вдасться, якщо це було семантично правильно. Отже, правильна семантика тут не застосовується.

— Харіш

4

@Tamer Чому так? Команда "Будь ласка, створіть об'єкт xy" синтаксично правильна. Семантично правильно, лише якщо можливо створити об’єкт xy. Якщо об’єкт xy вже існує, його більше не можна створити, отже, це смислова помилка.

— Хаген фон Ейтцен

47

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

Якщо сервер просто вказує дублікат , подивіться на 4xx:

400 Поганий запит - коли сервер не обробляє запит, оскільки це очевидна помилка клієнта
409 Конфлікт - якщо сервер не буде обробляти запит, але причина цього не з вини клієнта
...

Для неявного поводження з дублікатами подивіться на 2XX:

200 ОК
201 Створено
...

якщо очікується, що сервер щось поверне , подивіться на 3XX:

302 Знайдено
303 Див. Інше
...

коли сервер може вказати на наявний ресурс, це передбачає перенаправлення.

Якщо вищезазначеного недостатньо, завжди корисно підготувати деяке повідомлення про помилку в тілі відповіді.

— Славомір Ленарт
джерело

2

Запит не дублює ресурс, він додає дані до одного. На мою думку, ваша найкраща відповідь з усіх.

— Suncat2000

28

Можливо, пізно до гри, але я натрапив на це питання семантики, намагаючись зробити API REST.

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

10.4.4 403 Заборонено

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

Сьогодні хтось каже "403", і дозволу або проблеми автентифікації приходить на думку, але специфікація каже, що це в основному сервер, який каже клієнту, що він не збирається цього робити, не запитувати його знову, і ось чому клієнт не повинен 'т.

Що стосується PUTvs. POST... POSTслід використовувати для створення нового примірника ресурсу, коли користувач не має можливості або не повинен створити його ідентифікатор. PUTвикористовується, коли особа ресурсу відома.

9.6 PUT

...

Принципова відмінність запитів POST від PUT відображається в різному значенні Request-URI. URI у запиті POST ідентифікує ресурс, який буде обробляти додану сутність. Цей ресурс може бути процесом прийняття даних, шлюзом до якогось іншого протоколу або окремим об'єктом, який приймає примітки. На відміну від цього, URI у запиті PUT ідентифікує об'єкт, укладений із запитом - агент користувача знає, для чого призначений URI, і сервер НЕ МОЖЕ намагатися застосувати запит до якогось іншого ресурсу. Якщо сервер бажає, щоб запит було застосовано до іншого URI,

ОБОВ'ЯЗКОВО надіслати відповідь 301 (постійно переміщена); користувальницький агент МОЖЕ приймати власне рішення щодо перенаправлення запиту чи ні.

— p0lar_bear
джерело

7

Я думаю, що 403 Заборонено означає, що, незважаючи на те, що користувач має автентифікацію , він не має права виконувати запитувані дії. Я б не використовував його для помилок перевірки. Приклад : не ввійшов у систему, я намагаюся щось видалити. Сервер надсилає мені 401 Несанкціонований (який просто неправильно названий, повинен бути 401 Несанкціонований ). Я входжу та спробуйте ще раз. Цього разу сервер перевіряє мої дозволи, бачить, що я заборонений, і повертає 403 Заборонено . Дивіться також це питання .

— Штійн де Вітт

Гм ... правда. Думка тут стрибнула правом сказати користувачеві, що їх авторизація робить ресурс незмінним у випадку використання ОП - він уже існує, у вас немає дозволу нічого робити для вирішення конфлікту, не намагайтеся створити ресурс заново.

— p0lar_bear

3

Згідно з специфікацією, мається на увазі, що помилка 409 не може бути повернута POSTзапитом (при правильному використанні), оскільки в ній зазначено, що вона повинна бути повернута, коли вона суперечить цільовому ресурсу . Оскільки цільовий ресурс ще не розміщено, він не може конфліктувати, і, таким чином, відповідати 409 Conflictне має сенсу.

— Грант Гріцзан

1

Я б не зробив висновок про те, що помилку 409 не може бути повернуто a POST, насправді я б зробив зворотне, тому що "Конфлікти, швидше за все, виникають у відповідь на запит PUT". Схоже, вказує на те, що інші методи запиту також можуть використовувати цей код. Крім того, "Орган відповіді повинен містити достатньо інформації, щоб користувач міг розпізнати джерело конфлікту. В ідеалі, суб'єкт відповіді повинен містити достатню кількість інформації для користувача чи агента користувача, щоб усунути проблему; однак це може бути неможливим та є не потрібно ". ( webdav.org/specs/rfc2616.html#status.409 )

— JWAspin

14

"302 знайдено" для мене звучить логічно. І RFC 2616 говорить, що на нього МОЖЕ відповідати на інші запити, ніж GET і HEAD (а це, безумовно, включає POST)

Але він все ще тримає відвідувача за цією URL-адресою, щоб отримати цей "Знайдений" ресурс, RFC. Щоб перейти безпосередньо до реальної "Знайденої" URL-адреси, слід використовувати "303 See Other", що має сенс, але примушує черговий дзвінок отримати GET наступну URL-адресу. З іншого боку, цей GET є кешованим.

Я думаю, що я використовував би "303 See Other" . Я не знаю, чи можу я відповісти на "річ", знайдену в тілі, але я хотів би зробити це, щоб зберегти один переворот на сервер.

ОНОВЛЕННЯ: Після повторного читання RFC я все ще думаю, що неіснуючий код "4XX + 303 знайдено" має бути правильним. Однак "Конфлікт 409" є найкращим кодом відповідей (на що вказував @Wrikken), можливо, включаючи заголовок Location, що вказує на існуючий ресурс.

— аландс
джерело

88

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

— Aviram Netanel

1

"Запитаний ресурс тимчасово знаходиться під іншим URI." від w3.org/Protocols/rfc2616/rfc2616-sec10.html

— statueofmike

1

ІМХО, "307 тимчасового перенаправлення" - це справжня тимчасова переадресація. "302" неоднозначний, але "ЗНАЙДЕНО !!" тут справді бажане повідомлення. Найкращий однозначний компроміс - "303 See Other" в семантиці HTTP. Я б пішов з "303 Див. Інше".

— alanjds

@DavidVartanian Hum ... Я не бачу помилки тут. Клієнт надсилає правильний запит, але як сказати "Вибачте, але те, що ви намагаєтесь створити тут, вже існує ТО"? Здається, робота на 3 хв. Для мене це не 4xx, оскільки немає помилки клієнта.

— alanjds

1

@DavidVartanian Дякую за обговорення. Оновлено відповідь до 409 . Клієнт неправильно просить неможливі речі, навіть якщо він не знає, що це неможливо.

— alanjds

11

Я не думаю, що ти повинен це робити.

POST, як відомо, модифікує колекцію, і вона використовується для СТВОРЕННЯ нового елемента. Отже, якщо ви надсилаєте ідентифікатор (я думаю, це не дуже гарна ідея), ви повинні модифікувати колекцію, тобто змінити елемент, але це заплутано.

Використовуйте його для додавання елемента без ідентифікатора. Це найкраща практика.

Якщо ви хочете захопити UNIQUE обмеження (не ідентифікатор), ви можете відповісти 409, як це можна зробити в запитах PUT. Але не ідентифікатор.

— Альфонсо Тієнда
джерело

Що з об’єктом, що має відношення таблиці приєднання? Скажімо, у нас є таблиці облікових записів, продуктів і account_product як бази даних. Я хочу додати продукт до облікового запису, тому я хотів би опублікувати в / account / {id} / product з product_id. Якщо дозволено лише одне співвідношення рахунок-продукт, що я повинен повернути?

— partkyle

2

Забудьте про таблиці баз даних. Скажімо, продукт може бути пов’язаний лише з обліковим записом ... Тоді це відносини один до багатьох. Отже, POST / product / {id} із {'account': account_id}. Якщо у вас максимальна кардинальність встановлена на "1" (співвідношення один до одного) .... Чому вони розділені об'єктами відпочинку? Помилка кардинальності складе лише 400 помилок. Не ускладнювати. Я сподіваюся, що я зрозумів ваше запитання.

— Альфонсо Тієнда

Я просто поставив це питання і для мене ID - це не технічний ідентифікатор у базі даних, а щось на зразок коду компанії. У цій програмі користувач-менеджер може створювати компанії та повинен надати їм код. Це ідентифікатор компанії для користувача, незважаючи на те, що таблиця БД також має технічний ідентифікатор. Тож у моєму випадку я поверну 409, якщо той самий код компанії вже існує.

— AlexCode

@partkyle Перестаньте використовувати ПК як публічні ідентифікатори !!

— Сінестетик

Деякі суб'єкти мають унікальні обмеження на них, а не лише на ідентифікатор. Як і обліковий запис, ви не можете створити обліковий запис, якщо користувач не вказав ім’я користувача. І додати акаунт без імені користувача, очевидно, неможливо

— rocketspacer

9

Я б пішов з 422 Unprocessable Entity, який використовується, коли запит недійсний, але питання не в синтаксисі чи автентифікації.

Як аргумент проти інших відповідей, використання будь-якого 4xxкоду без помилок означає, що це не помилка клієнта, і, очевидно, є. Використовувати 4xxкод без помилок для представлення помилки клієнта просто не має сенсу.

Здається, 409 Conflictце найпоширеніша відповідь тут, але, згідно з специфікацією, це означає, що ресурс вже існує і нові дані, які ви застосовуєте до нього, несумісні з його поточним станом. Якщо ви надсилаєтеPOSTзапит, наприклад, із уже взятим іменем користувача, він насправді не суперечить цільовому ресурсу, оскільки цільовий ресурс (ресурс, який ви намагаєтесь створити) ще не розміщений. Це помилка спеціально для контролю версій, коли існує конфлікт між збереженою версією ресурсу та запитуваною версією ресурсу. Це дуже корисно для цієї мети, наприклад, коли клієнт кеширував стару версію ресурсу та надсилає запит, заснований на тій неправильній версії, яка більше не буде умовно дійсною. "У цьому випадку представлення відповідей, ймовірно, міститиме інформацію, корисну для об'єднання відмінностей на основі історії ревізії." Запит на створення іншого користувача з цим ім'ям користувача просто не підлягає обробці і не має нічого спільного з контролем версій.

Для запису 422 - це також код статусу, який GitHub використовує при спробі створити сховище за іменем, яке вже використовується.

— Грант Гріцзан
джерело

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

— rwenz3l

7

Я думаю, що для REST ви просто повинні прийняти рішення щодо поведінки для тієї конкретної системи, і в цьому випадку, я думаю, що "правильна" відповідь була б одним із пари відповідей, наведених тут. Якщо ви хочете, щоб запит зупинився і поводився так, ніби клієнт допустив помилку, яку йому потрібно виправити, перш ніж продовжувати, тоді використовуйте 409. Якщо конфлікт дійсно не такий важливий, і ви хочете продовжувати запит, тоді відповідайте, перенаправляючи клієнт юридичної особи, яку було знайдено. Я думаю, що належні API REST повинні перенаправляти (або принаймні надавати заголовок місцеположення) до кінцевої точки GET для цього ресурсу після POST, так що така поведінка дасть постійний досвід.

РЕДАКТУВАННЯ. Також варто зазначити, що вам слід розглянути PUT, оскільки ви надаєте ідентифікатор. Тоді поведінка проста: "Мені все одно, що там зараз, поклади цю річ". Значить, якщо нічого там немає, воно буде створене; якщо щось там є, його замінять. Я думаю, POST є більш доцільним, коли сервер управляє цим ідентифікатором. Відокремлення двох понять в основному говорить вам, як з цим боротися (тобто PUT є безсильним, тому він повинен працювати завжди до тих пір, поки корисне навантаження підтверджується, POST завжди створюється, тож якщо відбувається зіткнення ідентифікаторів, 409 описує цей конфлікт) .

— Синестетичний
джерело

Згідно з специфікацією, мається на увазі, що помилка 409 не може бути повернута POSTзапитом (при правильному використанні), оскільки в ній зазначено, що вона повинна бути повернута, коли вона суперечить цільовому ресурсу . Оскільки цільовий ресурс ще не розміщено, він не може конфліктувати, і, таким чином, відповідати 409 Conflictне має сенсу.

— Грант Гріцзан

Дискусійний imo. Якщо ви дописуєте до / користувачів, то ресурс - це колекція замість окремих записів / користувачів / {id}

— Sinaesthetic

Це помилка спеціально для контролю версій, коли існує конфлікт між збереженою версією ресурсу та запитуваною версією ресурсу. Це дуже корисно для цієї мети, наприклад, коли клієнт кеширував стару версію ресурсу та надсилає запит на основі тієї неправильної версії, яка б більше не була умовно дійсною. "У цьому випадку представлення відповідей, ймовірно, міститиме інформацію, корисну для об'єднання відмінностей на основі історії ревізії."

— Грант Гріцзан

Мені подобається ваша пропозиція використовувати, PUTхоча.

— Грант Гріцзан

4

Ще одне потенційне лікування - це використання PATCH. PATCH визначається як щось, що змінює внутрішній стан і не обмежується додаванням.

PATCH вирішить проблему, дозволивши оновити вже наявні елементи. Див.: RFC 5789: PATCH

— Мартін Керстен
джерело

2

Патч - це як PUT, але не є повноцінною заміною. Він використовується для зміни частини ресурсу, наприклад додавання, видалення або зміна одного елемента ресурсу замість заміни його в цілому.

— Сінестетик

4

Чому б не прийнято 202 ? Це ОК-запит (200-ті роки), помилок клієнта (400) не було, як наслідок.

З 10 визначень коду статусу :

"Прийнято 202. Запит прийнято до обробки, але обробка не завершена."

... тому що його не потрібно було завершувати, тому що воно вже існувало. Клієнт не знає, що це вже існувало, вони нічого поганого не зробили.

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

— Філіп Харрінгтон
джерело

21

Ця відповідь неправильна. 202 означає, що сервер не знайшов проблеми із запитом, але вирішив обробити запит після відповіді. Це також означає, що він очікує, що обробка буде успішною. У нашому випадку сервер знає, що обробка не вдасться, тому 202 - це неправильна відповідь.

— Адріан

4

Прикладом 202 може бути черга чи підписка. Іншими словами, результат запиту може бути недоступним одразу, якщо ви хочете запитати його прямо зараз.

— Сінестетик

1

Це було б доречно, якби сервер все ще обробляв запит. 200 або 204 було б частіше. Оскільки ОП робить запит на додавання, існування об'єкта є очікуваною умовою, а не помилкою.

— Suncat2000

Немає сенсу говорити клієнту, що запит прийнято, тому що ви вже знаєте, що його не було!

— lucaastamoios

1

@ Adrian та lucastamoios Я думаю, що ви обидва припускаєте, що сервер синхронно читає з бази даних, перш ніж надати відповідь. Це не завжди так, тому ця відповідь не є "неправильною", оскільки сервер не завжди "знає" про існуючий запис. Це дуже часто відбувається в асинхронних системах, де рівень api просто записує запити на обробку фоновими працівниками.

— gsaslis

2

Натрапили на це питання під час перевірки правильності коду для повторюваного запису.

Вибачте моє невігластво, але я не розумію, чому всі ігнорують код "300", який чітко говорить про "вибір" чи "неоднозначний"

На мою думку, це був би ідеальний код для побудови нестандартної чи певної системи для власного використання. Я можу помилитися також!

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

— Хітін
джерело

Я розумію: "Код статусу вказує на те, що цільовий ресурс має більше ніж одне представлення ... інформація про альтернативи надається, щоб користувач (або агент користувача) міг вибрати бажане представлення, перенаправляючи його запит на один або кілька із них ідентифікатори "Ми явно намагаємося запобігти більш ніж одне представлення. Немає варіантів. Немає альтернативи для вибору клієнта. Клієнт повинен повторно надіслати інший ідентифікатор. Зважаючи на це, слід також врахувати, чи слід створювати унікальні ідентифікатори на клієнті та сервері.

— musicin3d

Семантично клієнт говорить "Створити це", а сервер відповідає "Більше сюди". Розмова не має жодного сенсу. Це майже так, як ніби сервер каже клієнту "замість цього розмістити повідомлення в цьому місці". 300-ті - це більш відповідна відповідь на GET-запит або POST у випадку, коли сервер відповідає "Добре, я створив його і закінчилося тут" ..

— Sinaesthetic

2

Швидше за все 400 Bad Request

6.5.1. 400 Поганий запит

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

Оскільки запит містить повторюване значення (значення, яке вже існує), воно може сприйматися як помилка клієнта. Потрібно змінити запит до наступної спроби.
Розглядаючи ці факти, ми можемо зробити висновок як поганий запит HTTP STATUS 400.

— Мухаммед Безпечніший
джерело

1

Поганий запит означає, що існує властива проблема з синтаксисом пакету. Якщо в іншому контексті (наприклад, ресурс ще не існує) пакет отримав би успіх, то він не повинен повертати помилку 400.

— Грант Гріцзан

1

А як щодо 208 - http://httpstatusdogs.com/208- вже повідомлено ? Це варіант?

На мою думку, якщо єдине - це повторний ресурс, помилка не повинна виникати. Адже помилок немає ні на стороні клієнта, ні на сервері.

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

Це не варіант, оскільки ви хочете додати певний елемент, ідентифікатор якого вже існує. Тож ви намагаєтесь щось додати, але це вже є. ОК застосовується лише в тому випадку, якщо набір даних буде вирощений. Додайте щось -> Добре, я нічого не додав. Не підходить, я думаю.

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

Як я вже сказав, я не маю на увазі, це помилка. Але я бачу сенс @martin

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

Якщо ресурс не створено успішно, то за визначенням є помилка.

— Грант Гріцзан

POST також використовується для додавання даних. Це за визначенням , а не помилка .

— Suncat2000

@ Suncat2000 Навіть враховуючи, що це так, якщо дані не вдало додані, все ж є помилка. І якщо ресурс вже існує, дані не додаються.

— Грант Гріцзан