Ошибка входа в 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 (запрос) авторизирован с действительными учетными данными или без них.

Я хотел бы услышать некоторые оправданные мнения так или иначе. Каков стандартный способ решения этой проблемы и является стандартным способом обработки этого логически подходящего?

Ответ 1

Прежде всего. 401 - это правильный код ответа для отправки при неудачном входе в систему.

401 Несанкционированный Подобно 403 Forbidden, но специально для использования, когда требуется аутентификация, и не удалось или еще не предоставлено. Ответ должен включать поле заголовка WWW-Authenticate, содержащее вызов, применимый к запрашиваемому ресурсу.

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

Теперь я не знаю, как ведут себя службы, на которых вы смотрели. Но хороший способ решить это - иметь что-то вроде объекта Account, который вы пытаетесь ПОЛУЧИТЬ. Если ваши учетные данные верны, вы получите объект "Учетная запись", если вы не хотите тратить пропускную способность только на "проверку", вы можете делать HEAD на том же ресурсе.

Объект учетной записи также является хорошим местом для хранения всех этих досадных логических значений, которые в противном случае были бы сложными для создания отдельных ресурсов.