REST код відповіді для недійсних даних

Який код відповіді повинен бути переданий клієнту у випадку наступних сценаріїв?

1. Неправильні дані, передані під час реєстрації користувача, наприклад, неправильний формат електронної пошти
2. Ім'я користувача / електронна пошта вже існує

Я вибрав 403. Я також виявив, що я вважаю, що його можна використовувати.

Вікіпедія:

412 Попередня умова не виконана: сервер не відповідає одній з передумов, які запитувач поставив у запиті

Запропонуйте код, якщо я повинен використовувати інший, ніж 403.

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

412 - Попередня умова не виконана, використовується для умовних запитів при використанні останньої модифікованої дати та ETags.

403 - Заборонено використовується, коли сервер бажає запобігти доступ до ресурсу.

Єдиний інший вибір, який можливий, це 422 - Недоступна сутність.

Я б рекомендував 422. Це не частина основної специфікації HTTP, але вона визначається державним стандартом (WebDAV), і до неї слід обробляти браузери так само, як і будь-який інший код статусу 4xx.

Від RFC 4918 :

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

Якщо запит не вдалося правильно проаналізувати (включаючи суб'єкт / орган запиту), відповідна відповідь становить 400 поганих запитів [ 1 ].

RFC 4918 зазначає, що 422 об'єкт, що не обробляється , застосовний, коли запитуючий орган синтаксично добре сформований, але семантично помилковий. Тож якщо об'єкт запиту є зібраним (як неправильний формат електронної пошти), використовуйте 400; але якщо це просто не має сенсу (як @example.com), використовуйте 422.

Якщо проблема полягає в тому, що, як зазначено в запитанні, ім’я користувача / електронна адреса вже існує, ви можете використовувати 409 Conflict [ 2 ] з описом конфлікту та підказкою про те, як його виправити (у цьому випадку "виберіть інше ім’я користувача / електронна пошта "). Однак у специфікації, як написано, 403 Заборонено [ 3 ] також можна використовувати в цьому випадку аргументи про HTTP Авторизацію, незважаючи на це.

412 Попередня умова не виконана [ 4 ] використовується, коли заголовок запиту передумови (наприклад If-Match), який постачав клієнт, оцінюється як хибне. Тобто, клієнт щось просив і надав передумови, добре знаючи, що ці передумови можуть вийти з ладу. 412 ніколи не повинні бути виникли на клієнті блакиті, і не повинно бути пов'язане з об'єктом запиту на собі .

Повертатися 418 I'm a teapotдо запитів, які очевидно створені або зловмисні і "не можуть статися", наприклад, як невдача перевірки CSRF або відсутність властивостей запиту, забавно .

2.3.2 418 Я чайник

Будь-яка спроба заварювання кави з чайником повинна спричинити код помилки "418 Я чайник". Отриманий орган суб'єкта МОЖЕ бути коротким та кремезним.

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