Переговоры по поводу остального контента и кеширование

Question

Мне интересно, как кэширование работает с API на основе согласования контента.Поскольку для получения ресурса в XML или JSON, URI будет таким же, например:

http://example.com/bikes/mountain

Служба возвращает JSON / XML на основе заголовка типа Accept.Насколько умны кеши?

Например:

• если один клиент запросил это, используя тип Accept для возврата XML.
• ответ кэшируется веб-сервером, скажем, в течение 1 минуты.
• второй клиент запрашивает тот же ресурс, используя тип Accept, для возврата JSON

Проверяет ли кэширование проверку / типы контента вообще?Или это приведет к тому, что JSON-запросчик получит данные XML обратно, поскольку именно это было кэшировано сервером?Я надеюсь, что это что-то настолько очевидное, о чем уже позаботились, в противном случае, разве это не довольно большой аргумент для включения .xml / .json в URI?

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

Answer 1

Darrel верен в том смысле, что заголовок Vary сообщает клиенту, какие заголовки запроса могут варьироваться для получения разных представлений ресурса.

Это значение сообщает клиенту, что он может запросить представление в другом формате файла, установив или изменив заголовок Accept (в вашем случае, JSON или XML). Вы также можете получить другое представление вашего горного велосипеда на английском и французском языках, если вы используете заголовок Accept-Language.

Два запроса отправляют разные значения, поэтому они всегда должны кэшироваться отдельно.

Когда вы используете значение '*' в заголовке Vary, это означает, что ответ не должен кэшироваться.

Answer 2

Да. Посмотрите на описание заголовка Vary в RFC 2616

В моем упрощенном понимании заголовка var кэши будут использовать поля заголовка, которые названы в заголовке var, чтобы однозначно идентифицировать кэшированное представление.