REST - API дизайн для получения ресурсов для текущего пользователя - PullRequest
Новая
       25

REST - API дизайн для получения ресурсов для текущего пользователя

0 голосов
/ 03 марта 2020

У нас есть FitnessClassesService, который позволяет планировать занятия фитнесом. В каждом классе есть актеров :

  • Главный тренер , который объясняет всю тренировку - он все говорит, но не обязательно делает тренировок сам.
  • Заместитель тренера в случае отсутствия основного тренера
  • Два тренера , которые демонстрируют всю тренировку, фактически выполняя ее в классе - один для новичков и один для старожилов
  • Два тренера , которые просто передвигаются по классу, чтобы прояснить любые сомнения.

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

Я создаю классы, вызывая POST /classes.

Что бы правильный REST API для получения всех классов для тренера, когда они открывают свое приложение. Вот альтернативы, которые я рассмотрел:

  • Get /classes - Получить userId из заголовка HTTP и использовать его для получения классов только для текущего вошедшего в систему пользователя. Тем не менее, это не кажется мне очень RESTful.
  • GET /classes/~alice или Get /classes/current - С проектирование-Uri-для-текущий-во-во-во-во-пользователи-в-остальных приложениях Это получит только классы, представленные пользователем " current ". Однако, в отличие от примера в связанном вопросе, где ресурс " users " был ресурсом, а пользователь " current " представлял конкретный ресурс c, я не чувствую, что " current"представляет ресурс для моего варианта использования. « current » для меня представляет все классы, в которых я заинтересован. Похоже, мне нужно filter на ресурсе classes вместо того, чтобы запрашивать указанный c ресурс.
  • GET /classes?actorId=alice или GET /classes?actorId=current - Но что, если кто-то позвонит GET /classes. Должен ли я проверить, что actorId всегда должен быть передан. Кроме того, actorId должен совпадать с идентификатором вошедшего в систему пользователя. Можно ли делать такую ​​авторизацию на основе параметров URI.
  • Get /myclasses - Использовать другой URI. Это означает, что я буду создавать классы по POST /classes, но получу классы по другому URI.

Какой канонический способ справиться с этим.

1 Ответ

0 голосов
/ 03 марта 2020

Каким будет правильный REST API для получения всех классов для тренера, когда они открывают свое приложение

Если вы хотите REST API, первым делом нужно тщательно подумать о своем resources .

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

Концептуально, «расписание Алисы» и «расписание Боба» являются ресурсами. То же самое относится и к «Моему расписанию», но, конечно, у нас есть местоименная предшествующая проблема.

Есть два довольно простых способа обработать аутентифицированный запрос на «мое расписание»; вы можете ответить, перенаправив на правильный ресурс, и вы можете встроить текущее представление правильного ресурса в свой ответ (с метаданными, указывающими, откуда он пришел). Оба подхода: отлично .

(Примечание: RF C 7234 ограничивает кэширование аутентифицированных ответов, что является частью того, почему это "хорошо") .

REST не заботится о том, какое написание вы используете для своего URI (при условии, что оно соответствует производственным правилам, определенным в RF C 3986). Так что все это хорошо 

/classes/actorId=alice
/classes?actorId=alice

/classes/alice
/classes?alice

Используйте другой URI.

Все еще в порядке.

Одна из вещей, о которых вам нужно знать, это то, что аннулирование кэша связано с URI; когда вы отправляете POST в /classes, это делает недействительным ваше локально кэшированное представление /classes, но не локально кэшированное представление /myclasses. Это означает, что когда у вас есть одна и та же информация, закодированная в представлениях нескольких ресурсов, эти представления не обязательно будут синхронизированы.

...