REST коди статусу HTTP за невдалу перевірку або недійсний дублікат

Я будую додаток з API на основі REST і дійшов до того, що я вказую коди статусу для кожного запиту.

Який код статусу я повинен надсилати для запитів, які не мають перевірки, або де запит намагається додати дублікат у мою базу даних?

Я переглянув http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html, але жоден з них не здається правильним.

Чи є загальна практика при надсиланні кодів статусу?

Для помилки перевірки вводу: 400 Поганий запит + ваш необов'язковий опис. Про це пропонується у книзі " RESTful Web Services ". Для подвійної подачі: 409 Конфлікт

Оновлення червня 2014 року

Відповідною специфікацією раніше був RFC2616 , який давав використання 400 (Bad Request) досить вузько

Сервер не міг зрозуміти запит через неправильний синтаксис

Тож, можливо, можна було б стверджувати, що семантичні помилки непридатні. Але вже не більше; з червня 2014 року відповідний стандарт RFC 7231 , який замінює попередній RFC2616, дає ширше використання 400 (Bad Request), оскільки

сервер не може або не обробляє запит через те, що сприймається як помилка клієнта

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

Ви обов'язково повинні дати більш детальне пояснення в заголовках відповідей та / або тілі (наприклад, зі спеціальним заголовком - X-Status-Reason: Validation failed).

Я рекомендую код статусу 422, "Недоступний об'єкт" .

11.2. 422 Недоступна особа

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

200 300, 400, 500 - все дуже загальне. Якщо ви хочете загального, 400 - це нормально.

422 використовується все більшою кількістю API і навіть використовується Rails поза коробкою.

Незалежно від того, який код статусу ви обрали для свого API, хтось не погодиться. Але я віддаю перевагу 422, тому що вважаю "400 + статус тексту" занадто загальним. Крім того, ви не скористаєтеся аналізатором, готовим до JSON; на відміну від цього, 422 з відповіддю JSON є дуже явним, і можна передати велику кількість помилок.

Говорячи про відповідь JSON, я схильний стандартизувати відповідь на помилку Rails для цього випадку, а саме:

{
    "errors" :
    { 
        "arg1" : ["error msg 1", "error msg 2", ...]
        "arg2" : ["error msg 1", "error msg 2", ...]
    }
}

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

200

Фу ... (309, 400, 403, 409, 415, 422) ... багато відповідей, намагаючись вгадати, аргументувати та стандартизувати, що є найкращим кодом повернення для успішного запиту HTTP, але невдалого виклику REST .

Це неправильно змішувати HTTP коди статусу і коди стану спокою.

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

Коди повернення HTTP пов'язані з самим HTTP Requestсобою. Виклик REST виконується за допомогою запиту протоколу передачі гіпертексту, і він працює на нижчому рівні, ніж викликається самим методом REST. REST - це концепція / підхід, а її результат - діловий / логічний результат, тоді як код результату HTTP - транспортний .

Наприклад, повернення "404 не знайдено" під час дзвінка / користувачів / плутає, бо це може означати:

• URI неправильний (HTTP)
• Користувачів не знайдено (REST)

"403 заборонено / заборонено доступ" може означати:

• Потрібен спеціальний дозвіл. Браузери можуть це впоратися, запитуючи користувача / пароль. (HTTP)
• Неправильні дозволи доступу, налаштовані на сервері. (HTTP)
• Вам потрібно пройти автентифікацію (REST)

І список може продовжуватися "500 помилками сервера" (помилка, кинута HTTP Apache / Nginx або помилка обмеження бізнесу в REST) ​​або іншими помилками HTTP тощо ...

З коду важко зрозуміти, що було причиною відмови, помилкою HTTP (транспорту) або REST (логічним) збоєм.

Якщо запит HTTP фізично був виконаний успішно, він завжди повинен повертати 200 код, незалежно від того, знайдено чи ні запис. Оскільки ресурс URI знайдений та обробляється сервером HTTP. Так, він може повернути порожній набір. Чи можливо отримати порожню веб-сторінку з результатом 200 як HTTP, правда?

Замість цього ви можете повернути 200 HTTP-код з деякими параметрами:

• Об'єкт "помилка" в результаті JSON, якщо щось піде не так
• Порожній масив / об’єкт JSON, якщо запису не знайдено
• Прапор результату / успіху у поєднанні з попередніми параметрами для кращого керування.

Також деякі інтернет-провайдери можуть перехопити ваші запити та повернути вам 404 HTTP-код. Це не означає, що ваші дані не знайдені, але на транспортному рівні щось не так.

З Вікі :

У липні 2004 року британський провайдер телекомунікаційних послуг BT Group розгорнув систему блокування вмісту Cleanfeed, яка повертає помилку 404 у будь-який запит на вміст, визначений Фондом Інтернет-годин, як потенційно незаконний. Інші провайдери повертають HTTP 403 "заборонену" помилку за тих самих обставин. Практика використання підроблених 404 помилок як засобу для приховування цензури також повідомляється в Таїланді та Тунісі. У Тунісі, де цензура була жорстокою до революції 2011 року, люди усвідомили характер фальшивих помилок 404 і створили уявного персонажа на ім'я "Аммар 404", який представляє "невидимого цензора".

Чому б просто не відповісти чимось подібним?

{
  "result": false,
  "error": {"code": 102, "message": "Validation failed: Wrong NAME."}
}

Google завжди повертає 200 як код статусу в своєму API геокодування, навіть якщо запит логічно не відповідає: https://developers.google.com/maps/documentation/geocoding/intro#StatusCodes

Facebook завжди повертає 200 за успішні запити HTTP, навіть якщо запит REST не вдається: https://developers.facebook.com/docs/graph-api/using-graph-api/error-handling

Це прості коди HTTP для запитів HTTP. API REST - це ваш, визначте ваші коди статусу.

Дублікат у базі даних повинен бути 409 CONFLICT.

Я рекомендую використовувати 422 UNPROCESSABLE ENTITYдля помилок перевірки.

Я даю довше пояснення кодів 4xx тут .

Код статусу 304 Не змінено також дозволить прийняти відповідь на повторний запит. Це схоже на обробку заголовка за If-None-Matchдопомогою тегу сутності.

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

Якщо ви хочете трактувати дублікат запиту як попередження або сповіщення, а не як помилку, код статусу відповіді 304Not Modified і Content-Locationзаголовок, що ідентифікує існуючий ресурс, буде настільки ж дійсним. Якщо намір полягає лише у забезпеченні існування ресурсу, дублікат запиту не буде помилкою, а підтвердженням. Запит не є помилковим, але просто зайвим, і клієнт може звернутися до наявного ресурсу.

Іншими словами, запит хороший, але оскільки ресурс вже існує, сервер не потребує подальшої обробки.

Адаптер ActiveRecord Ember-Data очікує 422 UNPROCESSABLE ENTITYповернення з сервера. Отже, якщо ваш клієнт написаний на Ember.js, ви повинні використовувати 422. Тільки тоді DS.Errors буде заповнене поверненими помилками. Звичайно, ви можете змінити 422 на будь-який інший код вашого адаптера.