предоставлять / me конечные точки API, при этом предоставляя базовые c конечные точки, соответствующие тем же маршрутам

Question

Я хочу предоставить конечную точку me , потому что не у всех должен быть доступ ко всем ресурсам. Текущий авторизованный пользователь должен иметь доступ только к своим собственным ресурсам. Итак, давайте предположим, что у вас будет простой Todo REST API с конечной точкой, возвращающей все задачи от одного пользователя

GET /users/{username}/tasks

Текущий вошедший в систему пользователь не должен иметь возможность получать информацию о других пользователях. Возможное решение для этого:

GET /users/me/tasks

Это уже обсуждалось здесь

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

Проблема в том, что я также хочу сохранить конечную точку сверху для целей разработки (частная / скрытая конечная точка). К сожалению, обе конечные точки соответствуют одному и тому же маршруту. Итак, me может быть именем пользователя.

Я не хочу предотвращать использование имени пользователя me с if-оператором, например

if(username == "me")
    throw new ConflictException("Username 'me' is forbidden");

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

GET /users/me/tasks
GET /users/me/orders
POST /users/me/tasks
PATCH /users/me/username
DELETE /users/me/tasks/{taskName}

я мог бы удалить ресурс users и сделать me начальным базовым ресурсом. Как вы могли догадаться, /users/:username извлекает имя пользователя из параметра url, а /me извлекает имя пользователя из веб-токена json, но обе конечные точки работают с одним и тем же logi c.

Итак, если я хочу сохранить частные / скрытые конечные точки для получения пользователя по имени пользователя, нужно ли мне делать me отдельным ресурсом? Или есть способ оставить меня только в качестве замены параметра имени пользователя?

---

EDIT

Я попытался создать простой пример маршрута. Как видите, большинство конечных точек пользователей и меня зеркалируются и отличаются только идентификатором пользователя (имя пользователя как параметр или полезная нагрузка jwt). И в этом примере всем доступны только конечные точки me. Другие конечные точки являются частными / скрытыми.

users

GET / => get users => private
GET /:username => get user => private
GET /:username/tasks => get tasks from user => private
GET /:username/tasks/:taskName => get task from user => private
POST /:username/tasks => create user task => private
PATCH /:username/username => update username => private
DELETE /:username => delete user => private
DELETE /:username/tasks/:taskName => delete user task => private

tasks

GET / => get tasks => private

me

GET / => get current logged in user => public
GET /tasks => get tasks from current logged in user => public
GET /tasks/:taskName => get task from current logged in user => public
POST /tasks => create task for current logged in user => public
PATCH /username => update username => public
DELETE / => delete current logged in user => public
DELETE /tasks/:taskName => delete task from current logged in user => public

Answer 1

Я думаю, вы запутались, потому что ваши определения немного запутаны.

Вот хорошие новости: REST не заботится о правилах написания, которые вы используете для своих идентификаторов. Так что, если вам будет проще иметь

GET /users/12345/tasks
GET /me/tasks

, тогда вы можете реализовать оба из них, убедитесь, что ограничения доступа верны, и вы go.

Нет ничего неправильно, с точки зрения REST, об использовании

GET /users/12345/tasks
GET /users/me/tasks

Написание target-uri отличается, что означает, что с точки зрения клиента общего назначения они идентифицируют разные ресурсы.

НО ... реализация маршрутизации , которую вы используете для реализации своего API, может не позволить вам легко различить guish эти два случая. Фактически у вас есть два разных совпадения с одним и тем же шаблоном, что требует некоторого дополнительного ума, чтобы устранить двусмысленность; если ваша библиотека / фреймворк маршрутизации не предлагает этого, вам придется прокладывать его в себе. может соответствовать реальному идентификатору.

REST не имеет понятия «базовый ресурс» - по крайней мере, тот, который не соответствует тому, о чем вы думаете. С точки зрения REST, нет никакой внутренней связи между /users и /users/12345. Многие серверные структуры рассматривают обработку запросов как иерархию «ресурсов», но опять же: это деталь реализации вашего конкретного сервера.

REST действительно заботится только о вашем интерфейсе - вы понимаете HTTP-запросы стандартным способом .

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

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