Лучший способ управления обновлениями в приложении iOS client/server

У меня есть логистический вопрос: я пытаюсь понять, как лучше управлять API-интерфейсами, которые не синхронизируются с приложением. Лучший способ объяснить это с помощью примера:

Предположим, что MyApp Version 1.0 отправляет в API-адрес "submit_feedbacK", который требует first_name, last_name и email.

Затем я отправляю версию MyApp версии 2.0 в App Store. Эта версия предназначена для публикации first_name, last_name, gender и электронной почты для API. Все это обязательные поля в API.

Проблема у меня: - Если я обновляю API до того, как новое приложение будет вживую, оно сломает версию 1.0 - Если я жду, пока версия 2.0 будет жить и отдаленно калечит 1.0, я должен правильно ее исправить.

Я собираюсь догадаться, что "правильный ответ" - поддерживать два разных API. Но если оба API отправляются в одну и ту же живую базу данных, это делает вещи немного неудобными.

Есть ли у кого-нибудь предложения по моделированию этого?

Ответ 1

Этот вопрос может поделиться некоторыми аспектами с дизайном API для iOS.

Правильный ответ, безусловно, должен предоставить два API (по крайней мере, на короткий период времени, пока пользователи настраиваются). Вам не нужно одновременно поддерживать две версии, так как после выпуска более новой версии вы можете сохранить ее и просто предоставить старый для устаревших пользователей. Единственные реальные изменения, которые могут возникнуть для вас, - это такие вещи, как исправления безопасности или основные проблемы. Основные изменения (например, вы решите реструктурировать всю вашу базу данных) могут привести к тому, что старая версия больше не работает, однако обновление до новых версий API должно быть спроектировано таким образом, чтобы предыдущие версии все еще функционировали.

Другой вопрос, который я связал с вами, дает ответ о том, как вы можете использовать другую версию вашего приложения для правильной версии API.

Еще одно замечание: вам может быть проще (в зависимости от того, какую структуру вы используете) для разработки ваших API-интерфейсов в качестве движков или субпапсов и просто монтируйте их в разных конечных точках. Я знаю, что это легко сделать в Rails с помощью движков, а в Node с помощью Express с помощью app.use() с под-приложениями.

Ответ 2

Я бы использовал конечную точку webservice/http для связи с вашим приложением. Если вы предпочитаете поддерживать один и тот же URL-адрес во всех версиях приложения, укажите номер версии во всех запросах/сообщениях на сервере, чтобы он знал, как их обрабатывать. Это также облегчит разработку и тесты, так как новые версии могут протестировать новый api на сервере.

Таким образом, для любой функции, которую вы можете вызвать в webservice/server, добавьте одну переменную с номером версии. BYTE должно быть достаточно, поскольку я думаю, что вы могли бы начать все заново и "убить поддержку v1.0", как только вы нажмете 256 версий одной и той же функции (если когда-либо).

Как только сервер получает запрос/сообщение с данными, вы можете просто закодировать простую структуру switch/case в API-интерфейсе сервера, чтобы поддержка работала для обеих версий.

Если они делают подобное, но, например. свопирует параметры или что-то еще, вы можете обрабатывать все эти серверы, а BAL/DAL (структура n-уровня) можно поддерживать на серверной части решения.

Btw. мой ответ не только для iOS или smartdevices, но и для клиент-серверного подхода для производственной установки "незавершенного производства", где все должно быть в сети, все еще находясь в разработке и обслуживании.

Надеюсь, что это имеет смысл, иначе прокомментируйте это, и я попытаюсь объяснить это дальше.

Ответ 3

просто FYI, я использую CodeIgniter. Я использую контроллер REST при условии https://github.com/philsturgeon/codeigniter-restserver. В итоге я решил, что у меня есть разные конечные точки для каждой версии. В основном я бы проверил новый репозиторий для каждой версии и поместил его в уникальный каталог. (т.е. http://www.mysite.com/1.0/api/method, http://www.mysite.com/1.1/api/method и т.д.) Попытка поддерживать несколько версий API под одной кодовой базой просто казалась слишком страшной. По крайней мере, когда я выпустил версию, я бы знал, что она заперта в камне, и мне не нужно беспокоиться о ее нарушении. (Примечание: мне пришлось использовать специальную настройку .htaccess, чтобы получить несколько экземпляров CodeIgniter из одного домена. Я могу поделиться им, если хотите)