REST API и iPhone App Архитектура и структура кода

Question

Справочная информация: Я нахожусь на ранней стадии разработки приложения для iPhone и REST WebService. По сути, у меня есть база данных на сервере, и я написал несколько REST API для доступа к этой базе данных. У меня есть приложение для iphone, которое будет использовать эти REST API.

Вопросы: Каков наилучший подход для размещения кода для доступа к REST Apis? Должен ли я создать отдельный подкласс NSObject и поместить туда интерфейс и детали реализации? Я хотел бы уменьшить количество дублирования кода во всем приложении в различных контроллерах ViewController, которые будут взаимодействовать с REST API.

Например: Мое приложение запустится и выполнит вызов API REST, чтобы определить текущее состояние локальной информации на устройстве путем сравнения значения, возвращенного из API, с локальным. Затем я инициировал бы запрос на обновление от API, чтобы обновить локальное хранилище данных.

Теперь, если у меня есть вся эта логика в стартовом ViewController, у меня есть несколько вызовов с использованием NSURLConnection, который имеет только делегат. Я не знаю, как сделать эти отдельные вызовы в одном и том же ViewController.

Каковы некоторые подходы к решению этой проблемы?

Answer 1

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

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

Если вам нужно управлять несколькими запросами одного типа, вы можете добавить свойство «tag» в свой пользовательский запрос, чтобы при вызове вашего ответа делегата об успехе / неудачеВы можете легко определить, к какому запросу он относится, без необходимости сохранять переменную экземпляра в исходном запросе.