Зачем использовать XML (SOAP), когда JSON так прост и удобен в обращении? - PullRequest
52 голосов
/ 30 ноября 2011

Получение и отправка данных с помощью JSON осуществляется с помощью простых HTTP-запросов. Принимая во внимание, что в SOAP нам нужно заботиться о многих вещах. Синтаксический анализ XML также иногда труден. Даже Facebook использует JSON в Graph API. Я все еще задаюсь вопросом, почему все еще следует использовать SOAP? Есть ли какая-либо причина или область, где SOAP все еще является лучшим вариантом? (Несмотря на формат данных)

Кроме того, может ли SOAP в простых клиент-серверных приложениях (таких как мобильные приложения, подключенные к серверу) давать какие-либо преимущества перед JSON?

Я буду очень признателен, если кто-то сможет перечислить основные / заметные различия между JSON и SOAP, учитывая предоставленную мною информацию (если есть).

Ответы [ 4 ]

29 голосов
/ 30 ноября 2011

Я нашел следующие преимущества SOAP

  • Есть одна серьезная причина, по которой все придерживаются SOAP вместо использования JSON. С каждой настройкой JSON вы всегда придумываете свою структура данных для каждого проекта. Я не имею в виду, как данные закодированы и передается, но как определяется форматированный формат данных, данные модель.
  • SOAP предлагает зрелый способ указать, что данные будут Форма Корзина представляет собой набор продуктов, и каждый продукт может иметь эти атрибуты и т. д. Хорошо составленный документ WSDL действительно имеет это прибил. Черт, это спецификация W3C.
  • JSON имеет аналогичные способы указания этой структуры данных. JavaScript класс приходит на ум в качестве наиболее распространенного способа сделать это. Класс JavaScript на самом деле не является структурой данных Агностик, хорошо зарекомендовавший себя, широко используемый способ. Черт, JavaScript действительно выполняется только в одной среде, браузере.
  • Короче говоря, у SOAP есть способ указать структуру данных в зрелый формат документа (WSDL). У JSON нет стандартного способа сделать это.

Если вы создаете клиентское приложение и ваша реализация сервера выполняется с помощью SOAP, то вы должны использовать SOAP на стороне клиента.

Также см. здесь и здесь

21 голосов
/ 01 августа 2014

В настоящее время SOAP - это полное излишество, ИМХО.Было приятно использовать его, приятно изучать его, и прекрасно, что теперь мы можем использовать JSON.

Единственное отличие между службами SOAP и REST (независимо от того, используется ли JSON) состоит в том, что SOAP WS всегда имеетсобственный WSDL документ, который можно легко преобразовать в документ с самоописанием, в то время как в REST вы должны написать документацию для себя (по крайней мере, для документирования структур данных).Вот мои минусы и плюсы для обоих:

REST

Плюсы

  • легкий (во всех отношениях: не требуются серверные или клиентские расширения,нет необходимости передавать большие фрагменты XML здесь и там)
  • свободный выбор формата данных - вы сами решаете, можете ли вы использовать обычный TXT, JSON, XML или даже создать свой собственный форматданных
  • большинство современных форматов данных (и даже если используется XML) гарантирует, что только HTTP-поток действительно необходимого объема данных передается по HTTP, тогда как при использовании SOAP для 5 байтов данных требуется 1 КБ нежелательной памяти XML (преувеличено, конечно, но вы поняли)

Минусы

  • , даже если есть инструменты, которые могут генерировать документацию из комментариев docblock, необходимо писать такие комментарии в оченьописательный способ, если кто-то также хочет получить хорошую документацию(во многихязыки даже без них), который хорошо работает как документация
    • , даже есть инструменты, которые могут работать с WSDL, чтобы предоставить расширенный попробовать этот запрос интерфейс (пока я не знаю ни о каком таком инструментедля REST) ​​
  • строгая структура данных

Минусы

  • строгая структура данных
  • использует XML (только!) для передачи данных, в то время как каждый запрос содержит много ненужной информации, а ответ содержит в пять раз больше ненужной информации
  • необходимость внешних библиотек (для клиента и / или сервера, хотя в настоящее время такие библиотеки уже существуютнеотъемлемая часть многих языков, но люди всегда склонны использовать сторонние)

В заключение, Я не вижу большой причины предпочитать SOAP над REST (иJSON).Оба могут делать то же самое, есть встроенная поддержка кодирования и декодирования JSON почти во всех популярных web языках программирования, а с JSON вы получаете больше свободы, а HTTP-передачи очищаются от большого количества ненужной ненужной информации. Если бы я сейчас собирал API, я бы использовал REST с JSON.

6 голосов
/ 23 сентября 2014

Я немного не согласен с трендом JSON, который я вижу здесь. Хотя JSON намного проще, я бы сказал, что он довольно ограничен. Например, SOAP WS - это не последнее. Действительно, между мыльным клиентом и сервером у вас теперь есть шина корпоративных сервисов, схема аутентификации на основе криптозащиты, управление пользователями, отметка времени запросов / ответов и т. Д. Для всего этого есть несколько огромных программных платформ, которые предоставляют сервисы вокруг SOAP «веб-сервисы») и будет вводить вещи в ваш XML. Поэтому, хотя JSON, вероятно, достаточно для небольших проектов и на порядок проще, я думаю, что он станет довольно ограниченным, если вы отсоедините управление передачей и контент (т. Е. Вы разрабатываете контент, фактический сервер, но вся передача управляется другой командой, аутентификация еще одной командой, развертывание еще одной командой). Я не знаю, уместен ли мой опыт в большой корпорации, но я бы сказал, что JSON там не выживет. Слишком много ограничений помимо основной необходимости представления данных. Таким образом, проблема не в самом JSON RPC, а в том, что он пропускает дополнительные инструменты для управления сложностью, возникающей в сложных приложениях (не говоря о том, что то, что вы делаете, не является сложным, просто программное обеспечение отражает сложность компании, которая выдает)

1 голос
/ 06 февраля 2019

Я разработчик PHP / JS.Причина JSON проста.JSON == JS Object.

SOAP - это хорошо, но тяжело.Вопрос есть.Оно того стоит?Иногда да.Иногда нетИ в большинстве случаев вам все равно нужен JSON в конце.

Корпус использует SOAP, потому что они обмениваются данными с тысячами других объектов и им нужна целостность данных.Я думаю, что для небольших или средних проектов SOAP слишком тяжелый.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...