Конечные точки REST для текущего пользователя и ID

Question

Что касается API REST, какой структуре лучше следовать в целом?

Предположим, GET / PUT / POST / DELETE для всех ресурсов.

1) Использовать в настоящее время зарегистрированного пользователя для / users / ** / * маршруты.

/users
/users/password
/users/email
/users/preferences
/users/documents
/documents/:id

2) Иметь абсолютные пути с идентификаторами и использовать /users/:id для текущего вошедшего в систему пользователя?

/users
/users/:id/password
/users/:id/email
/users/:id/preferences
/preferences/:id

Имеет ли это значение?

Answer 1

Если ресурс, на который вы ссылаетесь, может быть несколько, вы должны указать

/resource/resource_id

В приведенном выше случае пользователь может быть только текущим человеком, поэтому использование шаблона, подобного /users/user_id, звучит странно. Потому что вам придется обрабатывать разные случаи, например, что, если вошедший в систему USER A инициирует вызов API с другим идентификатором пользователя USER B ??

У вас может быть пространство имен, например /profile, для управления электронной почтой, именем, изображением и т. Д. Вам не нужно указывать его как /users/profile, поскольку подразумевается, что данные будут обрабатываться / использоваться для текущий зарегистрированный пользователь.

Answer 2

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

Шаблон, который я использовал в недавнем API, заключался в создании уникальной конечной точки для каждого пользователя, но 1 конечная точка /current-user, которая перенаправляет на /user/:some-id.

URL может указывать на личность. Вполне логично, что другие ресурсы могут ссылаться на пользователя как на «создателя» или «модификатора» чего-то, и в этих местах вы можете использовать URL (а не просто userId).