ОТДЫХ: Как бороться с относительными ресурсами?

Я разрабатываю веб-приложение с React как front-end, и я пытаюсь правильно понять методы REST API. Чтение ресурсов в Интернете, можно понять, что REST API рассматривается как адаптер в базе данных. Однако что с «относительными» ресурсами? Например, те, которые связаны с текущим пользователем или текущим временем.

Я разрабатываю приложение, посвященное обучению, это «относительные» концепции, такие как «текущая неделя курса», очень важны.

Было бы лучше всего иметь одну конечную точку со всеми относительными данными, например: /api/me.json (так: идентификатор пользователя , его активный курс, текущая неделя курса и т. д.), и все остальное абсолютное, например:

    /api/user/[id]/course/progress.json литий> /api/user/[id]/course/week/[week_id]/progress.json литий>

Или, может быть, нормально иметь несколько относительных ресурсов, например: /api/me/course/progress.json

Или, может быть, даже: /api/me/course/current_week/progress.json (двойной относительный ресурс)?

Существуют ли установленные методы обращения с такими случаями?

3 голоса | спросил Luken 1 FriEurope/Moscow2017-12-01T18:41:00+03:00Europe/Moscow12bEurope/MoscowFri, 01 Dec 2017 18:41:00 +0300 2017, 18:41:00

2 ответа


3
  

Чтение ресурсов в Интернете, можно понять, что REST API рассматривается как адаптер в базе данных.

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

Короткий ответ: любой из ваших вариантов в порядке.

Первая часть для понимания - это понятие ресурса в архитектурном стиле REST.

  

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

«Текущий пользователь» и «текущая неделя» - вполне разумные концепции, поэтому, конечно, они могут быть ресурсами. «Текущая неделя» - это просто отображение, которое развивается относительно часов, «Текущий пользователь» - это просто сопоставление с оператором, связанным с текущим запросом. Там нет проблем.

Как отмечает Ewan, REST является апатридом - точнее, архитектурный стиль REST не позволяет вам хранить клиент состояние на сервере . Эффективно означает, что сообщение, возвращаемое сервером, может рассматривать только собственное состояние сервера в сочетании с данными, представленными в запросе. Другой способ думать об этом: запросы клиента не могут использовать местоимения без включения антецедента.

Таким образом, предполагая, что «текущий пользователь» относится к клиенту (например, оператор-оператор, работающий в браузере), в запросе должны быть данные, которые сообщают, с каким пользователем мы говорим. Это может быть информация, закодированная в самом идентификаторе ресурса, или она может быть включена в метаданные запроса (например, HTTP имеет Authorization , который может переносить эти данные).

Конечно, часть точки «текущей недели» заключается в том, что она изменяется; на следующей неделе отличается от прошлой недели. Алиса и Боб - разные «текущие пользователи». Поэтому необходимо соблюдать определенную осторожность с кэшированием ; убедитесь, что сервер явно сообщает (через метаданные), которому разрешено читать копии текущего представления, и как долго это представление может считаться действительным.

Для некоторых сценариев кэширования может оказаться полезным связать ответ с другим ресурсом с «каноническим» идентификатором. /user/alice может быть каноническим идентификатором для /me когда запрос Алисы обрабатывается; /2017-W48 может быть каноническим идентификатором для /current-week , Для различных вариантов использования вы можете перенаправить запрос на канонический ресурс, а чем обрабатывать его немедленно.

ответил VoiceOfUnreason 2 SatEurope/Moscow2017-12-02T08:24:25+03:00Europe/Moscow12bEurope/MoscowSat, 02 Dec 2017 08:24:25 +0300 2017, 08:24:25
0

Одна из ключевых вещей, возможно, ключевая вещь в REST - «Без гражданства».

Это означает, что вы не можете просто нажать /меня и знать, кто вы. Вы должны как-то отправить эти данные, а способ HTTP GET сделать это либо в пути, либо в строке запроса.

так

/users?id=myid

или

/users/myid

Чем позже будет «кулер». Точно так же, как и в текущую дату, лучше всего отправить нужную дату, а не направить сервер на текущее время из ОС.

например,

/courseProgress?userId=[id]&courseId=[courseId]&date=[utcdatetime]

Когда у вас есть несколько параметров, URL-адрес начинает становиться немного уродливым, поскольку он становится больше RPC, чем ресурс.

ответил Ewan 1 FriEurope/Moscow2017-12-01T20:03:57+03:00Europe/Moscow12bEurope/MoscowFri, 01 Dec 2017 20:03:57 +0300 2017, 20:03:57

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

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

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