Какой тип веб-сервиса лучше всего работает с iOS?
Я собираюсь создать внутреннее приложение для iPhone и iPad, которое будет отслеживать продажи звонков, связанные цитаты, фотографии и рисунки для этих цитат. Я все еще на стадии разработки концепции и пытаюсь узнать о различных способах взаимодействия между моим приложением и веб-сервисом. Очевидно, так как это будет использоваться в основном через 3G или... Edge Я хочу эффективный протокол, поэтому моя внутренняя реакция заключается в том, чтобы держаться подальше от основанных на XML вещей, таких как XML-RPC или SOAP. Я хотел бы использовать PHP и MySQL на сервере и планирую использовать Core Data на iOS.
Итак, у меня есть пара конкретных вопросов:
- Какую схему я должен использовать для производительности?
- Какую схему мне использовать для удобства работы на сервере?
- Какую схему мне использовать для простоты работы на iOS?
- Какую схему мне использовать, учитывая проект в целом?
- Является ли использование схемы на основе XML лучше, несмотря на нагрузку на сеть? Зачем?
2 ответа
Учитывая то, как вы задали несколько вопросов, вы, вероятно, понимаете, что конечным решением, которое вы используете, будет баланс между конкурирующими целями.
1: Вам нужно лучше определить "производительность". Я предполагаю, что вы имеете в виду время передачи по сети, что означает низкую задержку сервера и низкое количество передаваемых байтов. Конечным результатом, вероятно, является пользовательский протокол двоичного соединения, который также был проанализирован на предмет сжимаемости и сжатия, применяемых, где это необходимо (например, повторяющиеся строки или последовательности). Недостатком такого протокола является то, что, скорее всего, будет сложнее кодировать как на сервере, так и на клиенте, поскольку вы не сможете использовать поддержку SDK для стандартизированных кодировок, и если тщательно продуманные двоичные протоколы не станут хрупкими для поддержки будущих изменений и расширения для вашего приложения.
Также вы должны подумать о том, как вы определяете транзакции вашего протокола, даже с эффективной кодировкой, если ваш протокол требует многократных циклов или одного цикла, вы все равно будете медленными.
Наконец, в зависимости от размера данных, которые вы отправляете, накладные расходы на кодирование могут быть несущественными по сравнению с размером данных.
Я рекомендую придерживаться стандартизированного формата кодирования, который можно анализировать с помощью поддержки библиотек, который сужает поле до двух основных грамматик: XML или JSON.
2: XML и JSON хорошо поддерживаются в серверных инфраструктурах. При использовании сервисов XML я рекомендую шаблон стиля REST, так как его обычно легко построить, и вам не нужно согласовывать свое приложение с чьим-либо стилем.
Я бы держался подальше от веб-сервисов на основе SOAP, даже если их создание может хорошо поддерживаться (особенно на платформах Windows), потому что сложность выполнения полного анализа на основе SOAP для мобильного клиента высока и там не очень хорошо поддерживается. Я не нахожу автоматически созданную сериализацию объектов компиляторами WSDL такой большой выгодой для экономии времени при кодировании, обычно довольно легко сериализовать в XML-стиле REST или часто даже проще для JSON.
3: iOS поддерживает встроенный синтаксический анализатор XML в стиле SAX, и существует множество доступных библиотек классов, которые поддерживают реализации DOM в памяти с различными функциями и уровнями скорости. Выберите наиболее подходящий для ваших нужд. Я лично предпочитаю TBXML, который является быстрым, довольно легким и простым в программировании, но поскольку он не проверяет схемы и является деревом в памяти, он не подходит в некоторых ситуациях. Вот список производительности iOS XML-библиотеки.
Есть несколько библиотек JSON, доступных для iOS, если вы используете Google. Или посмотрите в этом ответе.
SOAP не очень хорошо поддерживается, и выбор библиотек ограничен. Вы всегда можете вручную проанализировать ответы SOAP, сгенерированные сервером, но это хрупко для изменений на стороне сервера, которые являются допустимыми SOAP (например, различные префиксы пространства имен), которые могут нарушить жестко закодированный анализатор XML.
4: Сложно ответить, не зная больше деталей вашего проекта, но я бы склонялся к JSON или простой кодировке на основе XML, потому что: и то, и другое обычно легко программировать на клиенте и на сервере, и то, и другое можно сделать с разумной эффективностью на провод, и, вероятно, будет расширяемым для будущих итераций приложения.
Преимущества JSON заключаются в том, что он немного проще для анализа, он может быть менее многословным, а также может быть проще повторное задание для других целей, таких как создание веб-клиента Ajax поверх ваших сервисов.
5: XML против JSON против других кодировок? Я думаю, что это личное предпочтение. XML может быть более самоописуемым, чем JSON, но, вероятно, будет больше работы для анализа. JSON может снизить издержки в необработанных байтах и его легко анализировать. Снова накладные расходы на кодирование могут быть значительными или незначительными в зависимости от размера вашего контента. Также вы можете применить внешнее сжатие в любом случае.
ОБНОВЛЕНИЕ: iOS5 теперь включает встроенную поддержку JSON с новым классом NSJSONSerialization. Вы можете прочитать руководство по использованию JSON с iOS5 здесь:
http://www.raywenderlich.com/5492/working-with-json-in-ios-5