Как создать URL для возврата данных от текущего пользователя в REST API?

у меня есть служба на основе REST, где пользователь может вернуть список своих собственных книг (это частный список).

URL в настоящее время ../api/users/{userId}/books

С каждым вызовом они также будут поставлять маркер аутентификации, поставляемый ранее.

мой вопрос(ы):

  1. поставляет userId в URL-адресе избыточно? Поскольку мы получаем токен с каждым вызовом, мы можем узнать, какой пользователь выполняет вызов, и вернуть их список книги. The userId строго не требуется.

  2. будет извлекать userId нарушить принципы отдыха как /users/books/ похоже, он должен вернуть все книги для всех пользователей?

  3. должен ли я просто укусить пулю и аутентифицировать их против токена, а затем проверить, что токен принадлежит тому же userId?

7
rest restful-authentication

3 ответов

короткий ответ:

вы могли бы использовать me в URL для ссылки на настоящее. При таком подходе у вас будет URL-адрес следующим образом:/users/me/books.

ответ на каждый вопрос

поставляет userId в URL избыточный? Когда мы получаем токен с каждым вызовом, мы можем узнать, какой пользователь выполняет вызов и вернуть свой список книг. The userId не строго требуемый.

вы могли бы рассмотреть возможность сделать что-то вроде этого: /users/me/books. Где me относится к настоящее. Это легче понять, чем /users/books, который можно использовать для возврата всех книг от пользователей.

для некоторой гибкости, кроме /users/me/books, вы могли бы поддержать /users/{userId}/books.

URL-адресом /users/me может использоваться для возврата данных от текущего пользователя. Многие APIs, такие как StackExchange, Facebook, Spotify и в Google+ принять такой подход.

будет извлекать userId принципы перерыва как /users/books/ похоже, он должен вернуть все книги для всех пользователей?

Я не думаю, что это нарушит какие-либо принципы отдыха, но я думаю, что ваши ресурсы не будут должным образом индетифицированы. Как я ответил выше, я бы использовал /users/me/books, а также .

должны Я просто стиснуть зубы и проверить их подлинность на маркер, а затем проверить, что маркер принадлежит к той же userId?

при использовании userId в URL для запроса частной информации от пользователя, нет никакого вреда в проверке, принадлежит ли токен пользователю с userId включено в URL.

6

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

С Наилучшими Пожеланиями

0

REST-это ресурсы, ориентированные так, что в вашей точке, что такое пользователь ресурса или книга. Моей точки зрения это книга. И я думаю, вы можете запросить эти ресурсы / api / книги?user={userid} Но этот URL-адрес не может решить проблему с разрешением, поэтому вы должны сделать это в своем коде с информацией токена, которую вы можете получить с помощью протокола OAuth2 или что-то еще.

-1