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

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

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

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

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

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

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

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

7 голосов | спросил ADringer 12 Jpm1000000pmTue, 12 Jan 2016 14:16:31 +030016 2016, 14:16:31

3 ответа


0

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

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

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

  

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

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

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

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

  

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

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

  

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

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

ответил Cassio Mazzochi Molin 12 Jpm1000000pmTue, 12 Jan 2016 14:47:53 +030016 2016, 14:47:53
0

Я не думаю, что удаление userId нарушило бы какие-либо принципы REST, потому что, в конце концов, /users и them /books, это немного открытое для интерпретации, а REST в принципе ничего не говорит об этом, с другой стороны, если вы собираетесь оставаясь с идентификатором внутри запроса, вы ДОЛЖНЫ проверить, что идентификатор пользователя совпадает с идентификатором подключенного пользователя, в любом случае, для меня 1 избыточен, потому что у вас уже есть эта информация, плюс каждый раз, когда вы собираетесь делать бесполезные проверки, потому что В любом случае, аутентифицированный userId - это тот, которому вы будете доверять во всех случаях.

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

ответил n0body 12 Jpm1000000pmTue, 12 Jan 2016 14:25:41 +030016 2016, 14:25:41
0

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

ответил Mr_Thorynque 12 Jpm1000000pmTue, 12 Jan 2016 14:33:02 +030016 2016, 14:33:02

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132