В REST вы говорите о ресурсах. Ресурс будет иметь определенное состояние, выраженное через их свойства.
С вашим примером я бы спросил себя: «зачем проверять электронную почту», «зачем проверять пароль». Потому что вы хотите проверить, может ли пользователь быть зарегистрирован. Таким образом, ваш ресурс не будет являться адресом электронной почты или паролем, кроме пользователя.
Проверка - это действие. Что-то плохое с REST architecture.
Что вы хотите проверить? Вы хотите зарегистрировать нового пользователя, но также проверить, разрешено ли ему регистрироваться. Поэтому вы попытаетесь с некоторыми условиями добавить пользователя в свою коллекцию пользователей. В REST с HTTP это можно сделать с помощью POST, который действует как add (User). Логика запроса может затем реализовать правила проверки для пользователя.
Для публикации данных просто используйте тело контента и используйте заголовки для получения дополнительной информации. Так что я бы изменить свой API для:
HTTP method: POST
Path: /users
Content-Type: application/json
Body:
{"email_address":"[email protected]", "password":"qlmkdjfmqlsk"}
что упрощает ваш API для одной точки входа для добавления пользователя. Разрешение или отказ от регистрации пользователя может быть передано посредством использования кодов состояния и сообщений HTTP.
Конечно, отправка паролей в текстовом виде не является хорошей практикой, но вы можете настроить безопасное соединение с SSL или TLS для связи.
Отправка конфиденциальных данных по URL-адресу не является хорошей практикой. Серверы могут регистрировать URL-адрес, который будет показывать всем, у кого есть доступ к журналу пароля пользователя.
Логин немного отличается, но не настолько.
Вам нужен ресурс, который однозначно связывает пользователя с его разговором с вашей системой.
HTTP method: POST
Path: /authentication
Content-Type: application/json
Body:
{"email_address":"[email protected]", "password":"qlmkdjfmqlsk"}
Response
Status-Code: 200
Content:
unique-id-to-my-user
аутентификации может вызвать ваш пользовательский интерфейс API, чтобы обеспечить соблюдение правил и затем генерировать идентификатор.
Чтобы справиться с этим, вы можете использовать реализацию OAuth2.
, пожалуйста, никогда не отправляйте конфиденциальные данные в URL-адрес или получить веб-службу, используйте POST для отправки данных на ваш бэкэнд в запросе тела. –