Я проектирую API ReST , который следует базовому шаблону CRUD .
Мой API может получить запрос на обновление ресурса, для обработки которого может потребоваться короткое время. В идеале я хотел бы проинформировать клиентов о том, что скоро будет доступна новая версия и что существует некоторая неопределенность относительно того, когда срок действия версии, которую я кэшировал, действительно истекает.
Итак, в процессе я собираюсь использовать что-то вроде этого (улучшения приветствуются):
client: GET /some/item
myapi: 200 OK
last-modified: time-stamp-of-v1
etag: some-hash-relating-to-v1-of-my-item-in-this-format
content: json or whatever
data/for/some/item/v1...
client: PUT /some/item
if-match: some-hash-relating-to-v1-of-my-item-in-this-format
content: json or whatever
data/for/some/item/v2...
myapi: 202 ACCEPTED,
content: json or whatever
time-accepted: time-stamp-after-v1-but-before-v2
your item will be at /some/item
here is a URI /some/taskid to track progress
пока идет загрузка:
client: GET /some/item
myapi: 200 OK
some/item ...
last-modified: time-stamp-of-v1
etag: some-hash-relating-to-v1-of-my-item-in-this-format
>>>> expires: time-stamp-after-v1-but-before-v2 <<<
>>>> warning: 110 Response is stale <<<<
content: json or whatever
data/for/some/item/v1...
client: GET /some/task/id
myapi: 200 OK
content: json or whatever
time-accepted: time-stamp-after-v1-but-before-v2
your item will be at /some/item
status/of/upload/v2...
после выполнения задания:
client: GET /some/item
myapi: 200 OKAY
some/item/v2 ...
last-modified: time-stamp-of-v2
etag: some-hash-relating-to-v2-of-my-item-in-this-format
content: json or whatever
data/for/some/item/v2...
client: GET /some/task/id
myapi: 303 SEE OTHER
look-here: /some/item
Если вы являетесь прокси-сервером и знаете, что ваш контент устарел, вы можете поставить «предупреждение: 110 - ответ устарел» в заголовке.
Однако в этом случае данные еще не являются недействительными.
Я хотел бы сказать, что могу гарантировать, что это действительно до тех пор, пока я не получу и не передам запрос на загрузку ( time-stamp-after-v1-but-before-v2 или позже, как если бы я был в контакте с сервером загрузки). На момент получения запроса на загрузку он еще не истек. Я просто ожидаю, что это будет.
(На самом деле, если запрос не выполняется, он может вообще не обновляться).
Теперь выбор по умолчанию - просто обслуживать старый контент и позволить клиенту догонять самостоятельно. Это имеет высокую задержку. Если возможно, я хотел бы сделать лучше.
Например, если клиент знает, что срок действия документа истекает, он может опрашивать чаще или может попытаться обновить соединение до веб-сокета и получить уведомление об обновлении, как только я его получу (это все равно будет считаться Rest?)
В другом случае следует избегать использования просроченных данных любой ценой. Для этого сценария я думаю, что хочу сказать клиенту, что ресурс временно недоступен. Использование полей «предупреждение» и «срок действия», как я указал выше, кажется правильным там. Хотя может быть лучше отправить 503 с подходящим заголовком повторной попытки.
Итак, вопрос: как мне ответить на GET, пока идет загрузка новой версии?
В ожидании ответов по принципу использования инфраструктуры обмена сообщениями, такой как AMQP или zeroMQ, вместо этого для низких задержек, я должен отметить, что этот API действует как шлюз / прокси-сервер AMQP для клиентов, не желающих использовать AMQP напрямую. Информация об использовании веб-хуков или веб-сокетов будет по-прежнему интересной.
Некоторая полезная информация: