Язык запросов для JSON

11

У меня есть сервер, который возвращает очень большое сообщение JSON, и мое клиентское приложение зависит только от части этого ответа. Клиентское приложение должно проверить, существует ли свойство «xyz» в сообщении JSON и, в зависимости от результата, запустить конкретный вариант использования.

Для этого требования преобразование всего сообщения JSON в объект звучит немного дорого для меня и, следовательно, этот вопрос.

Существует ли стандартный язык запросов JSON, такой как у нас для XML? Если да, что лучше всего знать реализацию этого языка запросов в Java.

К вашему сведению: изменение или добавление новой услуги на стороне сервера не вариант.

ферма
источник
В javascript, если ответ отправляется с правильным заголовком (application / json), ответ JSON будет объектом javascript. Это то, что вы просите? Я не уверен из твоего вопроса.
Флориан Маргейн
@Florian Я согласен, позвольте мне обновить мой вопрос и сделать его конкретным Java.
Ферма
Тогда, я полагаю, вы пробовали json.org/java ? :-)
Флориан Маргейн
Мне было интересно то же самое. Каждая библиотека Java для JSON, которую я видел, выглядит ужасно громоздкой; нет ничего подобного JSON.getString(json_string, 'foo.22.bar')(для свойства "bar" в 22 элементе списка в свойстве "foo", которое содержит строку)
Izkata
Или, чтобы избежать синтаксического анализа каждый раз, JSON baz = new JSON(json_string); baz.getString('foo.22.bar');например
Izkata

Ответы:

6

Почему бы просто не использовать JavaScript? (В конце концов, JSON - это нотация объектов Javascript). Тогда вам не придется анализировать или манипулировать JSON.

РЕДАКТИРОВАТЬ Посмотрите на http://json.org/java

Для этого требования преобразование всего сообщения JSON в объект звучит немного дорого для меня и, следовательно, этот вопрос.

Это не так. Десериализация объекта обходится дешево (самостоятельно протестируйте его на стенде). Разговор с внешним API будет на порядок дороже. Вы можете напрямую манипулировать строкой, которая может быть немного быстрее, но вы рискуете ошибками, снижаете расширяемость и читабельность. Высокая стоимость

Том Сквайрс
источник
Я обновил свой вопрос и сделал его специфичным для Java.
Ферма
Использование javascript неприменимо, так как клиентское приложение работает на головном устройстве, которое поддерживает только LWUIT
Ферма
2

«Мера, не угадай». Да, сериализация и десериализация объектов могут быть теоретически дорогими, но каковы цели производительности вашего приложения? Если сериализация (де) объекта не поднимает вашу производительность до неприемлемых уровней, не беспокойтесь об этом :-). Ключ, конечно, должен знать, какими должны быть границы производительности (например, время ответа пользователю в 2 секунды) и измерить каждую часть цикла запрос / ответ.

Мартейн Вербург
источник