Подтвердить что ты не робот

Схема JSON по сравнению с XML-схемой и их футуром

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

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

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

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

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

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

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

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

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

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

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

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

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

Ответ 2

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

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

  • JSON - это легкий способ (de) сериализовать и передавать ключ/значение и списки значений вокруг. Это легко, легко, удобно, а некоторые могут показаться более читаемыми, чем 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 сторонних сторон, это способ.

  • Конверсии назад и вперед - это идея BAD. Вы не можете просто преобразовать XML в JSON.

Ответ 3

Есть много альтернатив обмену данными, и мы рассматриваем 2 популярные технологии здесь. XML, как правило, больше, чем JSON, но XML более гибкий и может делать больше. Как КОКС и диетический кокс с точки зрения сахара.

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

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

Сжатие HTTP также может помочь хранить XML файлы по всему кабелю.

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

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

Ура!