Оставьте согласование содержания и кэширование
Я задаюсь вопросом как, кэшируя работы с содержанием основанный на согласовании API. Начиная с для получения ресурса в XML или JSON URI будет тем же, например:
http://example.com/bikes/mountain
Сервис возвращает JSON / XML на основе Принять заголовка типа. Насколько умный кэши?
Например:
- если один клиент запросил, чтобы это использование Приняло, что тип возвращает XML.
- ответ кэшируется веб-сервером для, говорит 1 минута.
- второй клиент запрашивает, чтобы то же использование ресурса Приняло, что тип возвращает JSON
Кэширование проверки принимает / типы контента вообще? Или это привело бы к запрашивающей стороне JSON, возвращающей данные XML, так как это - то, что кэшировал сервер? Я надеюсь, что это - что-то, таким образом, очевидное его уже заботившийся о, иначе, разве который не является довольно большим спором для включения .xml / .json в URI?
Я предполагаю, что мой вопрос в основном, я могу безопасно использовать согласование содержания при тихом использовании стандартных методов кэширования?
2 ответа
Даррел прав в том, что заголовок Vary сообщает клиенту, какие заголовки запроса он может изменять для получения различных представлений ресурса.
Это значение сообщает клиенту, что он может запросить представление в другом формате файла, установив или изменив заголовок Accept (в вашем случае, JSON или XML). Вы также можете получить другое представление своего горного велосипеда на английском и французском языках, если воспользуетесь заголовком Accept-Language.
Два запроса отправляют разные значения, поэтому их всегда следует кэшировать отдельно.
Когда вы используете значение «*» в заголовке Vary, это означает, что ответ не должен кэшироваться.
Да. Посмотрите описание заголовка Vary в RFC 2616
В моем упрощенном понимании заголовка Vary кеши будут использовать поля заголовка, названные в заголовке Vary, для однозначной идентификации кэшированного представления.