Дизайн REST API: Скажите серверу «обновить» набор ресурсов - PullRequest
11 голосов
/ 29 сентября 2010

У нас есть некоторые ресурсы на REST-сервере, структурированные так:

  • /someResources/foo
  • /someResources/bar
  • /someResources/baz

где someResource - серверное представление распределенного объекта далеко.

Мы хотим сказать серверу "обновить" свое представление этого "распределенного объекта", посмотрев на него всеть и обновление кэша сервера, т. е. мы не можем просто ПОСТАВИТЬ новое значение.

Каков чистый способ REST для этого?

a) Это POST для /refreshes/ нового"запрос на обновление"?

b) Это на PUT (с пустым документом) на http://ip/someResources?

c) Что-то еще?

Мне нравится (а)так как он даст нам идентификатор для идентификации и отслеживания команды обновления, но он обеспокоен тем, что мы создаем слишком много ресурсов.Любой совет?

Ответы [ 2 ]

5 голосов
/ 30 сентября 2010

Я бы пошел с ресурсным подходом «обновляет». Это имеет два основных преимущества

(a) Как и операции жизненного цикла (копирование, клонирование, перемещение), цель обновления ортогональна функции базового ресурса, поэтому должна быть полностью отделена

(b) Это дает вам некоторый способ проверки хода обновления - внешнее состояние ресурса обновления предоставит вам атрибут «status» или «progress».

Мы реализовали операции жизненного цикла таким образом, и разделение интересов является большим плюсом дизайна.


лучший подход

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


13.1.6 Управляемое клиентом поведение Хотя исходный сервер (и в меньшей степени промежуточные кэши по своему вкладу в возраст ответа) являются основным источником информации об истечении срока действия, в некоторых случаях клиенту может потребоваться контролировать решение кэша о том, возвращать ли кэшированный ответ без подтверждения. Клиенты делают это, используя несколько директив заголовка Cache-Control.

Запрос клиента МОЖЕТ указать максимальный возраст, на который он готов принять неподтвержденный ответ; указание значения ноль вынуждает кеш (ы) повторно проверять все ответы. Клиент МОЖЕТ также указать минимальное время, оставшееся до истечения срока ответа. Обе эти опции увеличивают ограничения на поведение кэшей и, следовательно, не могут еще больше ослабить кэш-аппроксимацию семантической прозрачности.

Клиент МОЖЕТ также указать, что он будет принимать устаревшие ответы, вплоть до некоторой максимальной степени устаревания. Это ослабляет ограничения на кеши и может нарушать указанные ограничения исходного сервера на семантическую прозрачность, но может быть необходимо для поддержки отключенной операции или высокой доступности в условиях плохой связности.

Chris

1 голос
/ 29 сентября 2010

HTTP-кэширование, кажется, учитывает это. http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.1.6

Установите заголовок max-age = 0, и это будет указывать серверу, что клиент хочет новую версию. Таким образом, вы можете просто продолжать использовать GET.

...