Разработка REST API: заголовок Accept против совместимости с веб-браузером

Question

Это вопрос стиля дизайна REST API

У меня есть API, который возвращает определенный ресурс и может возвращать либо поля ресурса в виде объекта JSON, либо представление ресурса в PDF-формате.Обычный способ сделать это - использовать тот же URL-адрес, но вернуть либо объект JSON, либо данные PDF в зависимости от заголовка «Accept» в запросе.

Это нормально при вызове API изклиентское приложение.Но сейчас я пишу веб-приложение и хочу показать PDF.Я могу получить данные PDF с помощью XMLHttpRequest, но нет простого способа их отобразить.(Я вспоминаю некоторый хак, связанный с передачей всего URL в кодировке base64, но это и ненадежно, и отвратительно).

Простой способ отобразить PDF в веб-приложении - window.open (),но я не могу передать ему заголовок Accept (здесь есть несколько вопросов для людей, спрашивающих, как это сделать).

Это кажется потенциально распространенной ситуацией.Какой лучший обходной путь?Вставьте? Pdf или / pdf или? Accept = pdf на URL?Есть ли де-факто стандарт?Или есть решение, о котором я не задумывался (возможно, рассматривая «application / pdf» как тип mime запроса по умолчанию и возвращая объект JSON, только если заголовок Accept равен «application / json»)?

Answer 1

На самом деле, чем больше я об этом думаю, тем больше последняя идея (возвращать PDF, если в заголовке Accept явно не указано application / json) кажется правильным ответом. Веб-браузер может отображать PDF-файлы (по крайней мере, обычно в наши дни), а не объекты JSON, поэтому запрос, сделанный изначально браузером, должен всегда получать PDF, а клиенты REST, которым нужны данные JSON, обычно явно запрашивают application / json, поэтому сервер API не должен делать это по умолчанию, если он имеет лучшую совместимую с браузером форму.

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