Какой код состояния HTTP я должен использовать для запроса GET, который может вернуть устаревшие данные?

Question

Сценарий таков: я реализую веб-сервис RESTful, который будет действовать как кеш для сущностей, хранящихся в удаленной системе Си. Одно из требований веб-службы заключается в том, что, когда удаленная система C находится в автономном режиме, она отвечает на запросы GET с последними кэшированными данными, но помечает ее как «устаревшую».

То, как я планировал пометить данные как устаревшие, возвращало код состояния HTTP, отличный от 200 (ОК). Я подумал об использовании 503 (служба недоступна), но я считаю, что это приведет к тому, что некоторые клиенты C # / Java HTTP будут генерировать исключения, а это косвенно заставит пользователей использовать исключения для потока управления.

Можете ли вы предложить более подходящий код статуса? Или я должен просто вернуть 200 и добавить флаг устаревания в тело ответа? Другим вариантом будет определение отдельного ресурса, который информирует о состоянии подключения, и позволяет клиентам обрабатывать это отдельно.

Answer 1

Просто установите заголовок Last-Modified соответствующим образом, и пусть клиент решит, устарел ли он. У устаревших данных дата последнего изменения будет дальше, чем «обычно». Для свежих данных сохраняйте заголовок Last-Modified текущим.

Answer 2

Я бы вернул 200 ОК и соответствующий ответ для конкретного приложения. Никакой другой код статуса HTTP не подходит, потому что решение о том, как и как использовать ответ, передается клиенту. Я также не рекомендовал бы использовать для этой цели стандартные заголовки управления кэшем HTTP. Я бы использовал их только для управления сторонними (посредническими и клиентскими) кешами. Использование этих заголовков для передачи информации о приложении необязательно связывает логику приложения с контролем кэша. Хотя это может быть неочевидно сразу, существуют реальные долгосрочные преимущества в способности независимо развивать логику приложения и стратегию кэширования.

Answer 3

Если вы обслуживаете устаревшие ответы RFC-2616 говорит:

Если сохраненный ответ не является "достаточно свежим" из-за самого строгого требования свежести как клиента, так иисходный сервер, при тщательно продуманных обстоятельствах, кеш МОЖЕТ по-прежнему возвращать ответ с соответствующим заголовком Warning (см. разделы 13.1.5 и 14.46), если только такой ответ не запрещен (например, директивой кеша без хранилища,или с помощью директивы cache-request «no-cache», см. раздел 14.9).

Другими словами, подача 200 OK - это прекрасно.

Answer 4

В статье о кешировании Марка Ноттингема он говорит

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

В вашем случае ваш веб-сервис ведет себя как промежуточный кеш.

Представление устарело, если прошел заголовок Expires или Max-age. Поэтому, если вы вернули представление с

Cache-control: Max-age=0

Тогда вы фактически говорите, что представление, которое вы возвращаете, уже устарело. Предполагая, что когда вы извлекаете из «Системы C» представления о том, что данные могут считаться свежими в течение некоторого ненулевого промежутка времени, ваш веб-сервис может возвращать представления с чем-то вроде

Cache-control: Max-age=3600

Клиент может проверить заголовок элемента управления кэшем для max-age == 0, чтобы определить, было ли представление устаревшим, когда оно было впервые получено или нет.