Как описать посредством JSON типы данных?

Question

[ksimmi]

Всем привет.

Есть несколько сервисов написанных на разных языках: Java, Ruby. Межсервисное взаимодействие происходит через Kafka, HTTP и БД. В случае HTTP и БД формат передачи JSON и это иногда приводит к проблемам, потому что разные языки и их библиотеки по-разному сериализуют/десериализуют свои типы данных в/из JSON по-разному. Ruby при сериализации в JSON приводbт Decimal к строке, оборачивая значение с кавычки. А вот Java сериализует Decimal в JSON, собственно, как число, т.е. без кавычек. Пример.

Ruby: Decimal->JSON = "1.0"
Java: Decimal->JSON = 1.0

Из этого всего вытекают проблемы, когда JSON был сериализован одним ЯП, а десериализован другим.

Мне кажется, тут есть два выхода из ситуации:
1 отказаться от JSON в пользу другого текстового формата, который поддерживает типы, но я не знаю ничего кроме XML и XML точно нет;
2 обогащать JSON дополнительными meta-данными о своих типах. Я думал о JSON Schema, но и тут Минусы. Во-первых он слишком громоздкий, во-вторых типа Decimal я там так и не увидел, в инете пищут про какой-то multipleOf-тип, но мне не понравилась идея.

Прошу подсказать решение.

Спасибо.

UPD.

Про protobuff знаю, использовал. Он бы мог нас спасти, но сейчас не вариант. Дело в том, что исторически у нас куча старых джава-сервсов, поддерживаемых 5-ю джава-командами, которые ничего кроме HTTP использовать не хотят, у этих сервисов полностью синхронное взаиможействие. Также с недавних пор есть около 18-ти руби-сервисов, они полностью асинхронны, не используют HTTP, только кафка. Когда-то планировался протобаф, но пока удавалось обходиться без него. Для взаимодействия джава и руби сервисов по HTTP на стороне руби поднят-сервис прослойка, обычный веб-сервер.

В целом проблема в том, что другие команды не хотят ни protobuff, ни Kafka.

Comments

[d'Ivan]

Помимо Decimal есть и другие проблемы?

[Vitsliputsli]

Вы передаете данные между подсистемами, какой тут может быть "формат, который поддерживает типы", типы у вас могут быть совершенно различные в разных подсистемах. Поэтому создавайте контракт для обмена данными и действуйте на основе него, и если надо преобразовывайте строки к числу.
А проблема скорее всего в том, что ваша библиотека в ruby не знает как отдать число с плавующей точкой, чтобы не потерять данные, поэтому и оформляет его как строку.

[ksimmi]

Роман Мирр, Нет, но это платежная система, поэтому это очень важно. Также хотелось бы с иметь тип данных Datetime, которого также в JSON нет, но это не так важно.

[ksimmi]

Vitsliputsli,

Вы передаете данные между подсистемами, какой тут может быть "формат...

А какая разница? Всегда можно передать метаинформацию о том как сериализованное представление данных преобразовать в нативные типы подсистемы. Это наверное единственный способ, я просто ищу какие-то общепринятые решения. Так, например, RPC работает под капотом.

ваша библиотека в ruby не знает

Все библиотека руби знает. Просто в руби реализовали сериализацию и десериализацию с использованием кавычек. Разработчики джава-библиотеки решили преобразовывать число 1.0 в Decimal, а разработчики руби во Float.

[Vitsliputsli]

ksimmi, тогда уже проще на protobuf перейти. Система которая загружает переданные данные, она же знает, что она грузит (есть же контракт на обмен данными?), если она знает, что переменная число, то нет большой разницы строкой оно прилетело или все же числом.
Это не "сериализация с использованием кавычек", это сохранение числа в виде строки, т.к. в json кавычки это признак строки. Такое "извращение" необходимо, чтобы обойти проблемы.

[d'Ivan]

1.0 нельзя однозначно отнести к decimal/float. Поэтому сериализуется как строка. Потому что можно толковать по-разному.

Answer 1

[d-stream]

Ну вообще зачастую для такого используют google protobuf

Comments

[ksimmi]

Я знаю про него и он бы мог нам помочь, но проблема историческая. Я со своей командой (три рубиста) пришли в большой проект с микросервисной архитектурой на Java, Java-разрабов было в момент нашего прихода 32 человека. На тот момент у нас даже немного питона и Го было. Так вот, у ребят все сервисы синхронно по HTTP общались, небыло никаких брокеров. Руби сервисы проектировались полностью асинхронными, мы подняли кафку, для мест где может потребоваться синхронность мы предполагали использовать protobuff, но он пока не требовался.

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

Поэтому я хочу найти решение вписывающееся в HTTP-протокол.

[d-stream]

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