О формате выходных данных

[Гимаев Наиль]

Для разработки нужен читабельный вид.
Для фронтенда нужна компактная запись без лишних пробелов.
Для бэкапов нужен заархивированый вариант.
Для мобильных устройств нужен json
Для старых корпоративных систем нужен xml.
Кому-то вообще нужен текст или yaml.

Изначально в odata есть параметр filter:
/collections/$allobjects?$format=zip
Мне больше нравится более коротка запись:
/collections/$allobjects.zip
Некоторые качалки берут имя файла из url, а не из заголовков. В первом случае скачается файл "$allobjects", а во втором "$allobjects.zip", хотя их содержимое должно быть эквивалентно.
Нужно рассматривать текст после точки не как формат, а как фильтр, на вход которому данные передаются в одном виде, а выходят в другом. Рассмотрим такую запись:
/collections/$allobjects.pretty.json.zip
/collections/$allobjects формирует компактный json (context.type="json") и передаёт его расширению (extension) которое зарегистрировано для "pretty". Pretty добавляет в context информацию, и передаёт данные в фильтр json, которое проверяет к какому формату относятся данные, если тип json, то данные приводятся человеко-читаемому виду, т.е. добавляются переносы строк и отступы, в соответствии с данными добавленными расширением pretty. Далее данные передаются в фильтр zip. Фильтр не проверяет к какому типу относятся данные, но на выходе меняет Content-Type на application/zip.
Для json, xml, txt важно в каком формате приходят данные, а для pretty, zip, rar, base64 это не имеет значения.

Пример

Переменная	До фильтра base64	После фильтра base64
context.text	'{"a":"1"}'	'eyJhIjoiMSJ9'
context.type	'json'	'base64'
context.contentType	'application/json'	'application/octet-stream'

Использование расширений позволяет переложить нагрузку по поддержанию форматов с databoom на разработчиков (т.е. пользователей databoom), а заодно предоставит пользователям гибкость, которую не может предоставить не один BaaS.