Согласование контента и расширенные типы медиа
Некоторые типы носителей являются расширениями других типов носителей. Такие типы носителей часто используют + в своем имени, чтобы сигнализировать об этом. Например, application/atom+xml расширяет универсальный xml, а application/hal+json расширяет универсальный json.
Мой вопрос: что делать, если клиент запрашивает универсальный тип медиа, а сервер хочет ответить одним из расширенных типов медиа? Например, если запрос имеет заголовок Accept: application/json и сервер хочет ответить приложением /hal+json, если сервер...
... доставить JSON с обычной Джейн с
Content-type: application/jsonне включать_linksили же_embeddeds? Это то, что клиент просил, и это то, что он получает. Если вы хотите HAL, попросите об этом.... доставить представление HAL с
Content-type: application/json? HAL, в конце концов, это JSON, и это то, что просил клиент. Клиент счастлив и может игнорировать биты, которые он не понимает.... доставить представление HAL с
Content-type: application/hal+json? Как и 2. клиент получает то, что он хочет, и может игнорировать биты, которые он не понимает. Но есть также подсказка, что клиент может получить больше от представления.
Я предпочитаю 3. Но есть ли спецификация, лучшая практика или общепринятый подход, который может предоставить руководство, которое является лучшим выбором?
1 ответ
Сервер может выполнить любое из трех действий или ответить 406 Not Acceptable если он не желает отвечать представлением по умолчанию.
Смотрите: http://tools.ietf.org/html/rfc7231