JSON или SOAP (XML)?

Question

Я разрабатываю новое приложение для компании. Приложение должно обмениваться данными с и на iPhone.

На стороне сервера компании используется .NET Framework.

Например: класс «Customer» (имя, адрес и т. Д.) Для определенного CustomerNumber должен быть сначала загружен с сервера на iphone, сохранен локально, а затем загружен обратно для применения изменений (и сделать их доступными для других людей) , Параллельность не должна быть проблемой (по крайней мере, в это время ...)

В любом случае мне нужно разработать как серверную часть (веб-сервис или что-то еще), так и приложение для iPhone.

Я свободен в определении лучшего способа сделать это (это приложение «номер ОДИН», поэтому оно станет «стандартом» на будущее).

Итак, что вы мне предлагаете?

Использовать веб-службы SOAP (синтаксический анализ XML и т. Д.) Или пользовательский JSON? (кажется светлее ...) Мне понятно, как «загружать» данные с помощью SOAP (очень долго, чтобы закодировать мыльный конверт xml ... я бы избегал), но как я могу сделать то же самое с помощью JSON?

Приложению необходимо использовать значения даты (например, last_visit_date и т. Д.), А как насчет даты в Json?

Answer 1

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

Его также проще использовать в коде javascript, так как вы можете просто передать пакет данных непосредственно в массив javascript без какого-либо анализа, извлечения и преобразования, что также значительно снижает нагрузку на процессор.

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

Вот учебник для начинающих .

Answer 2

Ах, большой вопрос: JSON или XML ?

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

При передаче вокруг небольших объектов данных, где единственные строки являются небольшими (идентификаторы, даты и т. Д.), Я склонен использовать JSON, так как он меньше, его легче анализировать и лучше читать.

Также обратите внимание, что даже если вы выберете XML, это никоим образом не означает, что вам нужно использовать SOAP. SOAP - очень тяжелый протокол, разработанный для взаимодействия между партнерами. Поскольку вы управляете здесь и клиентом, и сервером, это не обязательно имеет смысл.

Answer 3

JSON имеет следующие преимущества:

1. может кодировать логические и числовые значения ... в XML все является строкой
2. у него гораздо более четкая семантика ... в json у вас есть {"key":"someValue"}, в XML вы можете иметь <data><key>someValue</key></data> или <data key="someValue" /> ... любой узел XML должен иметь имя ... это не всегда имеет смысл ... и потомки могут либо представлять свойства объекта, либо потомки, которые при многократном возникновении фактически представляют массив ... чтобы действительно понять структуру объекта сообщения XML, вам нужна соответствующая схема ... в JSON, вам нужен только JSON ...
3. меньше и, следовательно, использует меньше пропускной способности и памяти при разборе / генерации ...

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

использование XML RPC или JSON RPC должно работать быстрее ... оно более легкое, и вы используете JSON или XML по своему желанию ... но при создании клиентских <-> серверных приложений очень важная вещь на мой взгляд, чтобы абстрагировать транспортный уровень с обеих сторон ... вся ваша бизнес-логика и т. д. ни в коем случае не должна зависеть от более чем крошечного интерфейса, когда дело доходит до связи, а затем вы можете подключать протоколы к своему приложению по мере необходимости ... .

Answer 4

Подумайте, как вы будете использовать результаты на iPhone. Какой механизм вы бы использовали, чтобы прочитать ответ веб-службы? NSXMLParser

Как вы потребляете данные, будет иметь наибольшее влияние на то, как вы их обслуживаете.

Являются ли JSON и SOAP единственными вариантами? А как насчет услуг RESTful?

Посмотрите на некоторых крупных игроков в Интернете, которые имеют общедоступные API-интерфейсы, доступные для клиентов iPhone:

API Twitter FriendFeed API

Кроме того, просмотрите следующие связанные статьи:

• Как разобрать вложенный JSON на iPhone
• Служба RESTful WCF, которая все еще может использовать SOAP
• Производительность REST против SOAP

Answer 5

Вы также можете использовать Hessian, используя HessianKit на стороне iPhone и HessianC # на стороне сервера.

Большие бонусы: 1. Гессиан в протоколе двоичной сериализации, поэтому меньшие полезные нагрузки данных, хорошо для 3G и GSM. 2. Вам не нужно беспокоиться о формате с обеих сторон, транспорт автоматизирован с прокси.

Итак, на стороне сервера вы просто определяете интерфейс C #, например:

public interface IFruitService {
  int FruitCount();
  string GetFruit(int index);
}

Тогда вы просто создаете подкласс CHessianHandler и внедряете IFruitService, и ваш веб-сервис готов.

На iPhone просто напишите соответствующий протокол Objective-C:

@protocol IFruitService
-(int)FruitCount;
-(NSString*)GetFruit:(int)index;
@end

Это может быть доступ через прокси с помощью одной строки кода:

id<IFruitService> fruitService = [CWHessianConnection proxyWithURL:serviceURL 
                                                          protocol:@protocol(IFruitService)];

Ссылки:

HessianKit: hessiankit

Answer 6

Есть больше опций, чем просто SOAP против JSON. Вы можете создать протокол на основе REST ( Передача состояния представления ) с использованием XML. Я думаю, что его легче использовать, чем SOAP, и вы получаете гораздо более приятный XSD (который вы разрабатываете). Практически любому клиенту довольно легко получить доступ к таким услугам.

С другой стороны, парсеры JSON доступны практически для любого языка и позволяют действительно легко вызывать из JavaScript, если вы будете использовать их через AJAX.

Однако SOAP может быть довольно мощным с тоннами стандартизированных расширений, поддерживающих корпоративные функции.

Answer 7

Я бы, конечно, пошел с JSON, как уже отмечали другие, - он быстрее и размер данных меньше. Вы также можете использовать среду моделирования данных, такую ​​как JSONModel, для проверки структуры JSON и автоматического преобразования объектов JSON в объекты Obj-C.

JSONModel также включает в себя классы для работы в сети и работы с API - также включает методы json rpc.

Посмотрите эти ссылки:

• http://www.jsonmodel.com - фреймворк JSONModel
• http://json -rpc.org - спецификация для реализации API JSON
• http://www.charlesproxy.com - лучший инструмент для отладки JSON APIs
• http://json -schema.org - инструмент для определения схем валидации для JSON, полезный по пути

Краткий пример использования JSONModel: http://www.touch -code-magazine.com / как к Make-A-YouTube-приложение, использующих-mgbox-и-jsonmodel /

Надеюсь, что это полезно