Проектирование URI для текущего зарегистрированного пользователя в приложениях REST

Question

Мне нужен URI в моем REST API для извлечения текущего зарегистрированного пользователя. Обычно я использую GET на ресурсе с идентификатором, но клиент не знает идентификатор пользователя.

Я нашел следующие решения:

• По имени пользователя

  Это решение использует имя пользователя вместо идентификатора пользователя.

  Пример:

  • Bitbucket REST API: GET /user/{userSlug}

• С собственным ресурсом

  Это решение имеет один ресурс для пользователей и один дополнительный ресурс для зарегистрированного пользователя.

  Примеры:

  • JIRA REST API: GET /myself

  • GitHub REST API: GET /user

  • Stack Exchange REST API: GET /me

• С символической ссылкой

  Это решение имеет символическую ссылку для ID пользователя.

  Пример:

  • Confluence REST API: GET /user/current

• С фильтром

  Это решение использует фильтр для имени пользователя.

  Пример:

  • JIRA REST API: GET /user?username={username}

Какой из них наиболее RESTful? Каковы плюсы и минусы?

Answer 1

Это зависит от вас. Все подходы отлично смотрятся с точки зрения REST.

Согласно диссертации Роя Томаса Филдинга ^*, любой информации, которая может быть названа может быть ресурсом:

5.2.1.1 Resources and Resource Identifiers

Ключа абстракцией информации в REST является ресурсом , Любая информация, которую можно назвать, может быть ресурсом: документ или изображение, временная служба (например, «сегодняшняя погода в Лос-Анджелесе»), коллекция других ресурсов, не виртуальный объект (например, человек) и т. Д. , Другими словами, любое понятие, которое может быть целью гипертекстовой ссылки автора, должно соответствовать определению ресурса. Ресурс представляет собой концептуальное сопоставление с набором объектов, а не с сущностью, которая соответствует отображению в любой конкретный момент времени. [...]

При использовании /me, /users/me, /users/myself, /users/current и похожести, у вас есть локатор для идентифицированного пользователяи она всегда будет определять концепцию аутентифицированного пользователя, независимо из которых пользователь аутентифицирован.

Для большей гибкости вы также можете поддерживать /users/{username}.

Кстати, подобная ситуация рассматривалась в Is using magic (me/self) resource identifiers going against REST principles?

---

^{* Если вы заинтересованы в остальном, chapter 5 диссертации Филдинга является обязательным читать.}

Answer 2

Все в равной степени RESTful. REST не относится к URI, это около , используя их RESTfully.

REST - это состояние приложения для навигации по клиенту. Частью этого состояния может быть тот, кто является текущим пользователем. Все URL-адреса могут использоваться для получения этой части состояния приложения.