JSON Schema по сравнению с XML Schema и их будущее - PullRequest
28 голосов
/ 24 марта 2012

Я искал стандарты схемы JSON и соответствующие им реализации php.Ожидая некоторого открытого исходного кода, я был удивлен, обнаружив только одну реализацию php.Я собирался использовать эту технологию (JSON) и схему lib для анализа моих входящих запросов браузера.

Эта естественная операция синтаксического анализа / проверки кажется естественной в XML, и я удивляюсь, почему это не так в JSON.

В итоге я сталкиваюсь с сомнительной ситуацией.Должен ли я продолжить обмен данными в своей структуре JSON или перейти на XML? Сначала я выбрал JSON из-за его простоты и менее подробного синтаксиса по сравнению с XML, но если мне придется пересмотреть весь существующий в мире стандарт, эти аргументы станут легче.Я также выбрал JSON, надеясь ограничить размер связи между моим веб-сервером и мобильными приложениями.Играя с кометными приложениями, XMPP, кажется, внедряется и используется такими громкими именами, как Google, Facebook, для их текстовых чатов в чате в реальном времени или сообщений на основе видео.

Итак, реальные вопросы:

  1. Является ли JSON плохим разработчиком веб-сервера, который хочет знать, что происходит с его трафиком, и сосредоточиться на простоте (не заблуждайтесь здесь, я включаю себя)?
  2. Черновик IETF для JSONСхема - серьезная работа, так как на стороне сервера (PHP) существует только несколько реализаций?
  3. Я что-то упустил, или, может быть, лучший способ связи - это отправлять данные в формате xml на сервер и ожидать jsonответ (в javascript существует много реализаций схемы json)?
  4. Или я только столкнулся с фактическим доказательством того, что сообщество разработчиков не приняло эту проблему, потому что веб-разработчик, использующий JSON, не проверяет глубоко свой входящий запросданные?

Пожалуйста, помогите мне понять, мне здесь не хватает опыта?

Ответы [ 4 ]

10 голосов
/ 25 марта 2012

Эта естественная операция синтаксического анализа / проверки кажется естественной в XML, и я удивляюсь, почему это не так в JSON.

Вспомните, что сделало JSON знаменитым: веб-приложения с очень богатымиПользовательский интерфейс написан на JavaScript.JSON идеально подходит для этого, потому что данные с сервера отображаются непосредственно на объекты JavaScript;нажмите GET URL с помощью Ajax и верните объект, не нужно разбирать или что-то еще.

Эти богатые интерфейсы сделали JavaScript очень популярным языком, и JSON, очевидно, стал популярным, и его популярность сделала его лучшим кандидатом на свержение «угловой скобки».

Но XML имеет давнюю историюЭто.Это зрелая технология с большим количеством сопутствующих спецификаций .JSON просто догоняет их.

Хотя срок действия проекта спецификации истек в мае 2011 года, сторонники схемы JSON считают, что достигли довольно близкой к окончательной версии спецификации.Итак, кто знает, что ждет в будущем схему JSON.

Я был удивлен, обнаружив только одну реализацию php [...] Действительно ли черновик IETF для схемы JSON является серьезной работой, посколькуна стороне сервера (PHP) существует несколько реализаций?

Проверяет ли эта реализация PHP JSON в соответствии с последней версией черновика схемы JSON?Если да, есть ли необходимость в других реализациях?Вам нужно много реализаций для сертификации серьезной спецификации?Это все равно что сказать, что XSLT 2.0 несерьезен, потому что Microsoft не удосужилась его реализовать .

Что касается вашего последнего вопроса, входящие данные должны быть проверены.Вы не принимаете запрос пользователя и не отправляете его на сервер, а «надеетесь, что он залипнет».Вы подтверждаете это;и схема JSON - не единственный способ проверки данных JSON, поэтому не думайте, что веб-разработчики, использующие JSON, не проводят глубокое тестирование данных своих входящих запросов.

В заключение я хочу сказать, чтоJSON не может полностью заменить XML или наоборот. Так что используйте каждую подходящую технологию .

8 голосов
/ 25 марта 2012

Вы задаете много разных вещей в своем вопросе, и я не уверен, что правильно понял, что вы действительно ищете, но вот некоторые мысли:

Хотя вы можете представлять данные как в JSON, так и в XML, они являются совсем другими.Я не буду даже пытаться быть точным здесь, но надеюсь дать вам правильную идею:

  • JSON - это легкий способ (де) сериализации и передачи ключа / значения и списковценности вокруг.Это легко, просто, удобно, и некоторые утверждают, что более читабельно, чем XML.Сериализация / десериализация легко выполняется на всех языках.

  • XML - это расширяемая разметка язык , которая не только представляет данные, но и задает правила (или протоколы, если хотите)о них.

Это относится не только к предоставлению схемы.Поскольку вы упоминаете XMPP, который выбирает XML для представления своих протоколов, рассмотрим следующий пример:

Предположим, что в некотором представлении на основе XML, предназначенном для обмена музыкальной информацией, где определен элемент <album>.

<album>The Contino Sessions</album>

Клиенты, разработанные для анализа этого XML, будут знать, как интерпретировать тег.Теперь Foo Bar может появиться позже и основываться на протоколе, расширяющем его так:

<album foobar:genre="Electronica">The Contino Sessions</album>

Старые клиенты, ничего не знающие о пространстве имен foobar, продолжат работать как обычно, игнорируя foobar:genre.Те, кто разбирается в foobar, проанализируют аннотацию жанра.Это иллюстрирует на примере, как XML не просто представление данных.Попробуйте подумать, как бы вы сделали то же самое с JSON.Вы найдете, что вы не можете с теми же ценами.Вот почему, например, очень маловероятно, что реализация XMPP может быть реализована в JSON.

Тем не менее, XML несет свое бремя.Трудно создать хорошие парсеры XML.Даже сложно использовать XML для простой сериализации.Читаемость человеком - это эвфемизм головной боли, когда дело доходит до выяснения длинных документов и т. Д.

Короче:

  • Когда вы просто передаете данные в JSON, это легко и просто.

  • Когда вы разрабатываете протокол, который будет расширен различными способами сторонними разработчиками, XML - это путь.

  • Преобразования туда и обратноплохая идея.Вы не можете просто конвертировать XML в JSON.

5 голосов
/ 25 марта 2012

Существует множество альтернатив обмену данными, и мы рассмотрим 2 популярные технологии здесь.XML обычно больше, чем JSON, но XML более гибок и может делать больше вещей.Подобно COKE и Diet Coke в терминах Sugar.

, если у вас есть сервисы, обслуживающие XML, тогда почему бы не создать адаптер для сериализации XML в JSON и обслуживать оба.Мы просто хотим избежать перестройки, добавив еще один слой.

Прочитайте.http://www.thomasfrank.se/xml_to_json.html

Сжатие HTTP также может помочь сохранить размер XML-файлов небольшим по проводам.

Скажем так.для сложных данных я буду использовать XML, для простых я буду использовать JSON.Я буду использовать оба.

как насчет будущего?Я скажу, что я не знаю.

Ура!

2 голосов
/ 25 марта 2012
...