Файлы в API

Добавка к прошлой заметке. В комментариях написали, мол, у вас стремный фреймворк, потому что передает только JSON. Как отдавать файлы? Лепите костыли со своим S3.

Дело вот в чем. Во-первых, да: у нас можно передать только данные, а файлы — нет. Все прибито гвоздями: пришел джейсончик, ушел джейсончик. Никаких файлов. Даже нет урлов как в этот вашем REST: все валится в один урл и там разгребается по полю command. RPC на коленке.

Во-вторых, мне это нравится. Когда вспоминаю REST, комбинации методов и урлов, утилиты вроде Swagger и OpenAPI, темнеет в глазах — это натуральная истерия. Все делают REST и затягивают десятки утилит, генерят хендлеры, не понимая, зачем и какую проблему они решают.

В-третьих, файлы. Я понял, что генерация файла и его раздача — разные вещи, и делегировать их нужно разным системам. Например, вы генерите файл и отдаете в клиенту в полете. А у клиента моргнула сеть, браузер делает повтор — и все по-новой. Вряд ли ваш код поддерживает заголовок Range, чтобы сгенерить байты с 100500 по 100999.

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

Поэтому удобно, когда файл уходит в какое-то хранилище, а клиенту дают временный урл со словами: на, забирай. Хочешь — курлом, хочешь — качай в браузере.

Примерно так устроена работа с файлами у айти-гигантов. Например, чтобы загрузить файл в VK, сначала дергают апишку с семантикой: я собираюсь загрузить картинку, тип такой-то, размер такой-то, название “prikol_2001.jpeg”. В ответ прилетает урлец, куда шлешь файлик методом POST.

То же самое, чтобы скачать файл: шлешь запрос “дай такой-то файл, вот координаты”, получаешь временный урл.

Важно, что апишка сервиса остается однородной. Она полностью одинакова: пришли данные — ушли данные. А если нужны файлы или стриминг, этим занимаются другие сервисы.