Блог

Главная - Вопросы по программированию - Ресурс REST для проверки наличия у ресурса существующих подресурсов

Ресурс REST для проверки наличия у ресурса существующих подресурсов

#rest

Вопрос:

Мое приложение предоставляет следующий ресурс:

 GET /user/:id/orders

Как обычно используется, это возвращает список всех заказов пользователя.

Теперь клиент хочет проверить, есть ли у пользователя вообще какие-либо заказы, фактически не получая полный список.

Мой нынешний подход выглядит так:

 GET /user/:id/orders/exist

Но мне это кажется несколько странным.

Существует ли более «стандартный» способ проектирования этого? В конце концов, этому ресурсу нужно только вернуть информацию:

  • да, у пользователя есть заказы
  • нет, у пользователя нет никаких заказов

Комментарии:

1. В зависимости от вашего дизайна вы можете либо вернуть 404 Not Found запрос GET /users/:id/orders на отсутствие заказов, либо просто вернуть ответ без ссылок на конкретные заказы в полезной нагрузке. Если ваш ресурс сбора данных поддерживает фильтрацию и разбиение на страницы, вы также можете использовать их для ограничения количества или возвращенных товаров в случае, если доступно больше заказов

Ответ №1:

То, что вы увидите в некоторых API, — это понятие ресурса, который существует (204) или не существует (404).

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

Ваша «модель ресурсов» может быть любой, какой вы захотите.

Интерфейс REST разработан таким образом, чтобы быть эффективным для передачи данных гипермедиа большого размера, оптимизируясь для общего случая Интернета, но в результате получается интерфейс, который не является оптимальным для других форм архитектурного взаимодействия-Филдинг, 2000

Таким образом, вы можете создавать мелкозернистые ресурсы, если хотите; но у этого могут быть последствия. «Компромиссы» — это вещь.

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

Если вы знаете, что такое отчет, то, возможно, сможете угадать название отчета, а затем его написание.

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

 /user/:id/orders/report
/user/:id/orders-report
/user/:id/report
/report/:id
/report?user=:id
/report/user=:id

Все это прекрасно; выберите тот вариант, который подходит для ваших местных соглашений.

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

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

Метки: