Можно ли маркировать один и тот же документ разными типами содержимого на основе заголовков Accept? - PullRequest
Новая
       13

Можно ли маркировать один и тот же документ разными типами содержимого на основе заголовков Accept?

2 голосов
/ 04 августа 2010

Допустим, я разработал тип носителя, который является строгим подмножеством другого типа носителя. Например, мой тип мультимедиа application/vnd.example.foo+xml (далее сокращенно foo+xml). Этот тип носителя является строгим подмножеством типа носителя application/xhtml+xml (далее сокращенно xhtml). По сути, мое определение типа носителя добавляет дополнительные инструкции по обработке (или полностью их заменяет) к определенным конструкциям в типе носителя xhtml. В качестве примера можно сказать, что в любых foo+xml документах xpath //ul[@class='foo']/li[a] должен показываться определенным образом клиентами, а остальная часть документа должна игнорироваться, модель обработки, которая весьма отличается от оригинального xhtml типа носителя.

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

У меня есть вариант:

  • Когда клиент предпочитает тип носителя foo+xml, я передаю документ с типом содержимого, установленным на этот тип носителя.
  • Когда клиент предпочитает тип носителя xhtml, я подаю тот же документ с заголовком xhtml Content-Type

Это означает, что универсальные клиенты, которые не знают, что такое foo+xml, но, вероятно, понимают, что такое xhtml, все еще могут обрабатывать мой документ, переходить по ссылкам на другие ресурсы, представлять его пользователям в общем виде и так далее. Аналогично, клиент, который знает семантику foo+xml, может фактически получить подтверждение того, что этот документ на самом деле является просто этим, вместо того, чтобы угадывать или анализировать документ, чтобы увидеть, выглядит ли он вообще как-то, что он может обрабатывать (например, через HTML). профилирование, микроформаты и пр.).

  1. Каковы плюсы и минусы этого
  2. Есть ли предшествующий уровень техники, который повторяет эту технику?

1 Ответ

1 голос
/ 04 августа 2010

Хотя я никогда не видел никаких авторитетных дискуссий по этому конкретному вопросу, я бы сказал, что это кажется вполне обоснованным. Это похоже на идею запроса текста / обычного для документа HTML для эффективного выполнения операции просмотра источника.

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

Я думаю, что каверза связана с кешированием. Собираетесь ли вы использовать один и тот же URI для возврата обоих представлений, или вы собираетесь перенаправить с универсального URI на специфичные для представления? Будут ли в кэше одна или две копии байтов? Нужно ли менять заголовок Vary в зависимости от типа контента? Можете ли вы жить с двумя копиями в кеше? Вам нужно обновить одно или оба этих представления? Если да, то сделает ли кеш недействительными обе копии, если они существуют?

...