YAML / JSON / XML: какой выбрать на IPhone для связи по протоколу RESTFul?

Question

Я пишу простое приложение, которое связывается с внешним сервером. В настоящее время сервер поддерживает yaml, xml и json.

• Какая кодировка самая быстрая на IPhone?
• Какая поддержка лучше?
• Какие библиотеки вы предлагаете?

Answer 1

Я работал над проектом, который связывал телефоны Motorola с J2ME с речевым сервером в сети. Мы обнаружили, что общую пропускную способность стоит оптимизировать (это было в сети 2.5G в 2004 году). Поэтому я бы посоветовал вам измерить, сколько байтов занимает каждый формат сериализации и идти с меньшим (который будет JSON или YAML). Вы можете даже подумать об использовании двоичного протокола, такого как Hessian или Google Protocol Buffers.

Мы также обнаружили, что минимизация числа сообщений снижает задержку, поэтому ищите способы отправки данных на iPhone за меньшее, более крупные куски, используйте кэш HTTP на вашем телефоне, используйте HTTP теги сущностей и заголовки If-Modified и т. д. Поскольку вы используете REST, вы можете использовать все эти замечательные функции HTTP.

Конечно, все это может быть очень преждевременной оптимизацией, поэтому закодируйте ее как можно проще и измерьте сначала.

Answer 2

Я создал приложение с открытым исходным кодом для iPhone OS 3.0, которое показывает, как использовать службы REST & SOAP в приложении iPhone, используя XML (используя 8 различных библиотек iPhone), SOAP, JSON (используя SBJSON и TouchJSON), YAML, Буферы протокола (формат сериализации Google) и даже CSV из примера приложения PHP (входит в проект).

http://github.com/akosma/iPhoneWebServicesClient

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

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

http://www.slideshare.net/akosma/web-services-3439269

В своих тестах я обнаружил, что Binary Plists + REST + JSON и XML + библиотека TBXML являются «лучшими» вариантами (что означает: простота реализации + скорость десериализации + минимальный размер полезной нагрузки).

В проекте Github есть папка «Results» с таблицей Excel, в которой обобщены результаты (и со всеми необработанными данными). Вы также можете запустить тесты самостоятельно в 3G или Wi-Fi, а затем отправить результаты по почте себе для сравнения и изучения.

Надеюсь, это поможет!

Answer 3

Используя json-framework , сделать ваши классы взаимодействующими с JSON до смешного просто.

Answer 4

ЕСЛИ у вас все в порядке с библиотекой c ++ в ваших проектах iPhone, тогда, пожалуйста, посмотрите YAML-каст :

http://code.google.com/p/yaml-cpp/

1. имеет встроенную поддержку iPhone (через систему сборки cmake)
2. не имеет зависимостей кроме хорошего компилятора и cmake
3. очень дружественен к c ++ (таким образом, название) с солидной документацией (см. Страницу wiki / HowToParseADocument)

Answer 5

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

http://www.servicestack.net/benchmarks/NorthwindDatabaseRowsSerialization.1000000-times.2010-02-06.html

По сути, если вы разрабатываете с помощью веб-сервисов .NET, вы будете идти на компромисс между размером полезной нагрузки и производительностью, если не будете использовать другой сериализатор.

Protobuf-net от Marc показывает наименьшую и самую быструю реализацию:

• 6,72 раза быстрее и в 4,68 раза меньше, чем самый быстрый Xml Serializer от MS; и
• 10,18 раза быстрее и в 2,24 раза меньше, чем MS JSON DataContract Serializer;

Хотя это двоичный протокол, его может быть сложнее отладить.

Если вы разрабатываете с MonoTouch (например, C # / Mono для iPhone) и хотите использовать текстовый формат, вас может заинтересовать мой сериализатор Javascript-подобного типа , оптимизированный для размер и скорость, он также демонстрирует скромный выигрыш по сравнению с доступными опциями XML и JSON, а именно:

• в 3,5 раза быстрее и в 2,6 раза меньше, чем сериализатор XML DataContract; и
• в 5,3 раза быстрее и в 1,3 раза меньше, чем сериализатор JSON DataContract.

Вот учебник MonoTouch, показывающий, как вызывать веб-сервисы с iPhone: http://www.servicestack.net/monotouch/remote-info/

Answer 6

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

То же самое с XML - есть куча - просто искать вокруг.

Это также зависит от того, какие типы носителей поддерживает ваш сервер - кстати, REST на самом деле не протокол.

Answer 7

есть поддержка всех трех форматов в Objective-C. Просто Google для них. Я бы предложил написать сериализатор, который поддерживает все три. Просто завершите запрос URL-ресурса расширением .xml | .json | .yaml, и пусть сервер решит, что сериализировать на основе этого расширения. Тогда вам на самом деле не нужно решать, что вы можете переключиться на что угодно. Сделать подключаемый сериализатор действительно легко в большинстве реализаций на стороне сервера.

Answer 8

Я не видел никаких библиотек YAML (хотя это не значит, что их нет). Я знаю, что TouchJSON работает довольно хорошо, и есть по крайней мере еще один.

JSON занимает меньше места, чем канал XML или PLIST, НО нужно заранее подумать над тем, чтобы получить правильную структуру.

Одним из приятных аспектов pLists является то, что вы возвращаете даты в виде объектов без разбора. Если вы передаете даты в формате JSON, определитесь с форматом и везде используйте один и тот же формат. NSDateFormatter не является потокобезопасным, поэтому вам нужно создать экземпляр для каждого потока, если вы хотите использовать один форматировщик даты для экономии ресурсов.

Answer 9

Это действительно зависит от ваших потребностей и от того, какие данные вы собираетесь передавать между сервером и приложением.Если вы хотите выполнить запросы для выбора некоторого фрагмента данных, вам следует выбрать XML из-за поддержки языка XQuery.JSON не поддерживается, как я знаю.Я ничего не могу сказать о YAML.