Поддержка обратной совместимости в сервис-ориентированной архитектуре на стороне клиента

Question

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

Итак, сценарий заключается в том, что клиент находится в обновленной версии (например, 2.0), а API-интерфейсы веб-служб не являются (например, 1.0).

В этом случае мне нужно найти шаблон, в котором клиент обновленной версии может получить доступ и использовать API веб-сервисов более старой версии.

Может ли кто-нибудь предложить решение для этого же.

Примечание. Мои приложения встроены в iOS и Android соответственно.

P.S .: Я не могу заставить обновлять API веб-сервисов.

Пример:

Моя старая версия приложения (1,0) имели возможность вводить обязательное поле, которое было проверенную в бэкенд веб-сервиса (1.0).

Теперь моя последняя версия приложения (2.0) не требует отображения поля вообще (, что делает его необязательным), но мое приложение (2.0) по-прежнему обращается к веб-службам версии 1.0, поэтому всякий раз, когда я делаю запрос, сервер ответит сообщением об ошибке, указывающим, что это поле необходимо, и не позволит мне сохранять данные.

Выражаясь простыми словами:

У меня есть несколько развертываний серверного кода и мой клиент будет доступ к этим серверам. Код сервера может быть любой версии (1.0,2.0,3.0), но мой клиент всегда будет в последней выпущенной версии. (Например, 3.0). Такому же клиенту по-прежнему требуется доступ к серверам с 1.0, 2.0 и 3.0

Как обращаться с такими сценариями?

Answer 1

Мне нужно найти шаблон, в котором клиент обновленной версии может по-прежнему получать доступ и использовать API более старой версии.

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

---

Различные URL Paths

Самый простой ответ на этот вопрос заключается в иметь свой API веб-службы a/v #/внутри самого URL-адреса. Таким образом, вы можете легко отличить вызовы от разных версий API.

так www.myserver.com/webapi/v1/songs/author/ и www.myserver.com/webapi/v2/author/songs/, например

---

Different (Sub) Домены

Другой подход заключается в v1 веб-интерфейсы работают на одном (суб) домена и есть v2 на другой .. . www.v1.myserver.com/webapi/songs/author против www.v2.myserver.com/webapi/songs/author или использовать myserverv1.com против myserver2.com и т.д.

Answer 2

Если вы r Web API «требует» этого поля, тогда ваше приложение должно «предоставить» это поле. Получается ли он от Пользователя или нет. Если пользователь не заполняет/не предоставляет это поле, вам нужно просто ввести в свой API-запрос «что-то действительное» (это будет зависеть от того, что это за поле, от вашего API и т. Д.), А затем оттуда.