Невдача входу в систему RESTful: повернення 401 або власна відповідь

Це концептуальне питання.

У мене є клієнтський (мобільний) додаток, який повинен підтримувати вхід у систему щодо веб-сервісу RESTful. Оскільки веб-сервіс RESTful, це означає, що клієнт приймає ім'я користувача / пароль від користувача, підтверджуючи це ім’я користувача / пароль за допомогою сервісу, а потім просто пам'ятає надіслати це ім'я користувача / пароль з усіма наступними запитами.

Усі інші відповіді в цій веб-службі надаються у форматі JSON.

Питання полягає в тому, що коли я запитую веб-сервіс просто, щоб дізнатись, чи вказане ім'я користувача / пароль є дійсними, чи веб-служба завжди відповідає на дані JSON, повідомляючи мені про її успішність чи невдалість, чи повинен повернути HTTP 200 на хороших облікових даних та HTTP 401 на помилкових облікових даних.

Причина, яку я запитую, полягає в тому, що деякі інші сервіси RESTful використовують 401 для поганих облікових даних навіть тоді, коли ви просто запитуєте, чи справді дані облікових даних дійсні. Однак, як я розумію, відповіді 401 полягають у тому, що вони являють собою ресурс, до якого ви не повинні мати доступ без дійсних даних. Але ресурс для входу повинен бути доступним для всіх, оскільки вся мета ресурсу для входу полягає в тому, щоб повідомити вам, чи ваші облікові дані дійсні.

По-іншому, мені здається, що запит на зразок:

myservice.com/this/is/a/user/action 

повинен повернути 401, якщо надано невірні дані. Але запит на зразок:

myservice.com/are/these/credentials/valid

ніколи не повинен повертати 401, оскільки ця конкретна URL-адреса (запит) дозволена з дійсними обліковими даними або без них.

Я хотів би почути так чи інакше обґрунтовані думки з цього приводу. Який стандартний спосіб поводження з цим і чи є стандартний спосіб поводження з цим логічно доцільним?

По-перше. 401 - це правильний код відповіді, який потрібно надіслати, коли сталося невдале вхід.

401 Несанкціонований подібний до 403 Заборонено, але спеціально для використання, коли потрібна автентифікація та не виконана або ще не надана. Відповідь повинна містити поле заголовка WWW-Authenticate, що містить виклик, застосовний до запитуваного ресурсу.

Ваша плутанина з приводу того, що ви myservice.com/are/these/credentials/validнадсилаєте 401 назад, коли ви просто робите перевірку, я думаю, що заснована на тому, що робити булеві запити в REST часто неправильно обмеженнями RESTful. Кожен запит повинен повертати ресурс. Буйні питання у службі RESTful - це слизький ковз до RPC.

Зараз я не знаю, як поводяться служби, які ви подивилися. Але хороший спосіб вирішити це - мати щось на зразок об’єкта Account, який ви намагаєтеся отримати. Якщо дані облікового запису правильні, ви отримаєте об’єкт Account, якщо ви не хочете витрачати пропускну здатність лише на "перевірку", ви можете зробити HEAD на тому ж ресурсі.

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

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

Відповідно до стандарту тут https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

* 10.4.2 401 Несанкціоновано

У запиті потрібна автентифікація користувача. Відповідь ОБОВ'ЯЗКОВО включатиме поле заголовка WWW-Authenticate (розділ 14.47), що містить виклик, застосовний до запитуваного ресурсу. Клієнт МОЖЕ повторити запит у відповідному полі заголовка Авторизація (розділ 14.8). Якщо запит вже включав в себе дані авторизації, відповідь 401 вказує на те, що авторизація відхилена для цих даних. Якщо відповідь 401 містить такий самий виклик, що і попередня відповідь, і користувальницький агент вже намагався пройти автентифікацію принаймні один раз, тоді користувачеві ПОТРІБНО представити сутність, яку було надано у відповіді, оскільки ця сутність може містити відповідну діагностичну інформацію. Аутентифікація доступу до HTTP пояснюється в розділі "Автентифікація HTTP: основна та дайджест аутентифікації" [43]. *

Поверніть 409 із правильним повідомленням про помилку.