Подтвердить что ты не робот

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

Я собираюсь создать внутреннее приложение для iPhone и iPad, которое будет отслеживать звонки продаж, связанные кавычки, фотографии и рисунки для этих котировок. Я все еще на стадии разработки концепции, и я пытаюсь прочитать различные способы связи между моим приложением и веб-сервисом. Очевидно, так как это будет использоваться в основном по 3G или... Edge Я хочу эффективный протокол, поэтому моя реакция на кишок должна держаться подальше от XML-подобных вещей, таких как XML-RPC или SOAP. Я хотел бы использовать PHP и MySQL на сервере и планировать использование Core Data на iOS.

Итак, у меня есть несколько конкретных вопросов:

  • Какую схему я должен использовать для производительности?
  • Какую схему следует использовать для упрощения работы с сервером?
  • Какую схему я должен использовать для удобства работы с iOS?
  • Какую схему я должен использовать, рассматривая проект в целом?
  • Является ли использование схемы на основе XML лучше, несмотря на сетевые издержки? Почему?
4b9b3361

ОТВЕТЫ

Ответ 1

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

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

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

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

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

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

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

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

Существует несколько JSON-библиотек для iOS, если вы используете Google. Или посмотрите в этом ответе.

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

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

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

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