Правильный маршрут проверки ресурса в RESTful API

Какой лучший/спокойный способ разработки конечной точки API для проверки наличия ресурсов?

Например, есть пользовательская база данных. Пока новый пользователь пытается зарегистрироваться, я хочу проверить, использовалось ли электронное письмо "на лету".

Моя идея: POST/user/exists а полезная нагрузка будет похожа на {"email": "[email protected]"}. Ответ будет либо 200 OK, либо 409 Conflict.

Правильно ли это?

Благодарю!

Ответ 1

HEAD является наиболее эффективным для проверки существования:

HEAD /users/{username}

Запросите путь пользователя и верните 200 если они существуют, или 404 если они этого не сделают.

Имейте в виду, что вы, вероятно, не хотите показывать конечные точки, проверяющие адреса электронной почты. Он открывает дыру безопасности и конфиденциальности. Имена пользователей, которые уже публично отображаются вокруг сайта, например, reddit, могут быть в порядке.

Ответ 2

GET /[email protected]

Это базовый поисковый запрос: найдите пользователей, у которых указан указанный адрес электронной почты. Ответьте на пустую коллекцию, если пользователей нет, или не отвечайте пользователям, которые соответствуют условию.

Ответ 3

Я считаю, что правильный способ просто проверить существование - использовать глагол HEAD для любого ресурса, который вы обычно получите с помощью запроса GET.

Недавно я столкнулся с ситуацией, когда я хотел проверить наличие потенциально большого видеофайла на сервере. Я не хотел, чтобы сервер попытался запустить потоки байтов для любого клиента, поэтому я внедрил ответ HEAD который только что вернул заголовки, которые клиент получит при выполнении запроса GET для этого видео.

Вы можете проверить здесь спецификацию W3 или прочитать это сообщение в блоге о практическом использовании глагола HEAD.

Я думаю, что это потрясающе, потому что вам не нужно думать о том, как сформировать свой маршрут иначе, чем обычный маршрут RESTful, чтобы проверить наличие какого-либо ресурса, будь то файл или обычный ресурс, например, пользователь или что нибудь.

Ответ 4

Я предпочитаю:

HEAD /users/email/[email protected]

Объяснение: Вы пытаетесь найти всех пользователей, которые используют электронную почту [email protected]. Я предполагаю, что электронная почта не является ключом к вашему ресурсу, и у вас есть определенная гибкость, потому что если вам нужен другой конечный пункт, чтобы проверить доступность другой информации от пользователя, этот подход может очень хорошо подходить.

В качестве ответа вы возвращаете только 200 (если оно не доступно) или 404 (если доступно) в качестве ответа на код http.

Вы также можете использовать:

HEAD/emails/[email protected]

если HEAD/users/email/[email protected] конфликтует с существующим ресурсом отдыха, например GET/users/email/[email protected] с другим бизнес-правилом. Как описано в документации Mozilla:

Метод HEAD запрашивает ответ, идентичный запросу GET, но без тела ответа. *.

Итак, у GET и HEAD с разными правилами не получается.

HEAD/users/[email protected] - хороший вариант, если электронное письмо является "ключом" users, потому что у вас (возможно) есть GET/users/[email protected].