Какой веб-сервис работает лучше всего с iOS?

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

1: Вам нужно лучше определить «производительность». Я предполагаю, что вы имеете в виду время передачи по сети, что означает сохранение низкой задержки сервера и количества передаваемых байтов. Конечным вариантом, вероятно, является настраиваемый протокол двоичной проводки, который также был проанализирован на предмет сжимаемости и сжатия, применяемого там, где это необходимо (например, повторяющиеся строки или последовательности).Обратной стороной такого протокола является то, что, вероятно, будет сложнее кодировать как на сервере, так и на клиенте, поскольку вы не сможете использовать поддержку SDK для стандартизованных кодировок, и, если не продуманные двоичные протоколы будут хрупкими для поддержки будущих изменений. и расширения вашего приложения.

Также вам следует подумать о том, как вы определяете транзакции вашего протокола, даже если для вашего протокола требуется много циклов приема-передачи по сравнению с одним циклом приема-передачи, вы все равно будете медленными.

Наконец, в зависимости от размера данных, которые вы отправляете, накладные расходы на кодирование могут быть несущественными по сравнению с размером данных.

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

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

Я бы держался подальше от веб-сервисов на основе SOAP, даже если их создание может хорошо поддерживаться (особенно на платформах Windows), потому что сложность выполнения полного анализа на основе SOAP на мобильном клиенте высока и плохо там поддерживается. . Я не считаю, что автоматически сгенерированная сериализация объектов компиляторами WSDL является такой большой победой для экономии времени при кодировании, обычно довольно легко сериализовать в XML-стиль в стиле REST или часто даже проще для JSON.

3: iOS поддерживает встроенный синтаксический анализатор XML в стиле SAX, и существует множество доступных библиотек классов, которые поддерживают реализации DOM в памяти с различными функциями и уровнями скорости. Выберите тот, который лучше всего подходит для ваших нужд. Я лично предпочитаю TBXML, который является быстрым, довольно легким и простым в программировании, но поскольку он не проверяет схемы и является деревом в памяти, он не подходит в некоторых ситуациях. Вот пример производительности библиотеки XML для iOS.

Если вы погуглите, для iOS доступно несколько библиотек JSON. Или посмотрите этот ответ .

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

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

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

5: XML против JSON против других кодировок? Я думаю, это личное предпочтение. XML может быть более самоописательным, чем JSON, но, вероятно, потребует больше работы для анализа.JSON может иметь меньшие накладные расходы в необработанных байтах и ​​его легко анализировать. Опять же, накладные расходы на кодирование могут быть значительными или могут быть незначительными в зависимости от размера вашего контента. Также в любом случае можно применить внешнее сжатие.