Обновить

Комментарии 2

Но тем самым вы жёстко привязали свою версию JSON-RPC к HTTP, в то время, как

It is transport agnostic in that the concepts can be used within the same process, over sockets, over http, or in many various message passing environments.

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

Замечание про дух спецификации справедливое, но фича устроена ровно наоборот: ядро протокола не тронуто. В multipart-запросе полный JSON-RPC request object едет нетронутой JSON-строкой в поле jsonrpc - method, params, id и ответ ровно те же, что и в обычном запросе. Это не «версия JSON-RPC», а опциональный транспортный биндинг, выключенный по умолчанию: метод, который его явно не объявил, отвечает -32600, а application/json работает как работал.

Привязка к HTTP - свойство самого бандла, а не этой фичи: это Symfony-бандл, который отдаёт JSON-RPC поверх HTTP. Сокеты и очереди сообщений вне его рамок независимо от multipart.

Насчёт base64 - спецификация 2.0 про бинарные данные не говорит вообще ничего, так что "должны" тут уже интерпретация. Base64 в строковом параметре работал и работает без какой-либо поддержки со стороны бандла, и в документации он прямо назван правильным ответом для мелких файлов - иконка, подпись, миниатюра. Multipart добавлен для случая, где base64 объективно плох: плюс треть к размеру на проводе и весь файл в памяти на обеих сторонах - при кодировании, при json_decode, при валидации.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации