кодирование версий мобильного устройства для сервера REST Api - PullRequest
Новая
       10

кодирование версий мобильного устройства для сервера REST Api

1 голос
/ 15 октября 2010

У нас есть успокоительный API по HTTP.Среди других клиентов у нас также есть клиенты для мобильных устройств (например, iphone).Проблема в том, что существует несколько приложений для iPhone в разных версиях (1.0, 2.0).Поскольку они распространяются, мы не можем контролировать, какая версия приложения нам звонит.

Чтобы определить версию приложения на стороне сервера, я вижу следующие параметры:

  1. устройство должно добавить параметр URL (например, /foo?iphone-app-version=1.0): Aнемного неприятно, но хорошо, что я всегда вижу это в журналах сервера (URL всегда регистрируется)
  2. мы аутентифицируем api-клиентов с помощью дайджеста HTTP.Мы могли бы закодировать версию приложения внутри имени пользователя (например, iphone_1_0): хорошо, что оно регистрируется в журналах сервера, но работает только для ресурсов, которые представлены как дайджест HTTP.
  3. устройство должно использовать пользовательский HTTP-заголовок, например, X-IPHONE-APP-VERSION: На мой взгляд, самый чистый подход, но мы не регистрируем HTTP-заголовки в журналах сервера (для log-noise он отключен).Поэтому последующий анализ невозможен.

У вас есть предпочтительный подход или какие-либо другие альтернативы?

РЕДАКТИРОВАТЬ: С вышеупомянутым версионированием я не имею в виду api-versioning / content -gotiation.Это версия мобильного устройства.

Ответы [ 2 ]

1 голос
/ 15 октября 2010

Вы можете использовать Accept-Header, чтобы позволить клиенту объявить о своих возможностях, указав, какие версии типов носителей он поддерживает.например,

мобильное приложение выполняет: 

GET /server/foo
Accept:  application/vnd.acme.fooappV1+xml

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

GET /server/foo
Accept:  application/vnd.acme.fooappV2+xml

Тогдаваш сервер знает возможности клиента, с которым он разговаривает.Вы также можете заставить новых клиентов делать это: 

GET /server/foo
Accept:  application/vnd.acme.fooappV1+xml, application/vnd.acme.fooappV2+xml

Таким образом, вы можете медленно переносить ресурсы сервера в новый формат.Если конечные точки доставят application/vnd.acme.fooappV1+xml, тогда клиент вернется к старому способу.Если конечные точки возвращают application/vnd.acme.fooappV2+xml, то новый код может вступить во владение.

При использовании этого подхода не нужно изменять URI, поэтому закладки и статистика остаются действительными.Миграция в новый формат может выполняться постепенно, а поддержка старых клиентов постепенно прекращается.

0 голосов
/ 21 октября 2010

Я выбрал специальный X-xxx-USER-AGENT. Основная причина, по которой следует отказаться от более стандартного «агента пользователя», заключается в том, что он уже «загрязнен» библиотекой http-клиента или информацией мобильного устройства. Пользовательский X-xxx-USER-AGENT легче анализировать на сервере и не вмешивается в http-библиотеку, которая часто устанавливает его и может переопределить пользовательскую запись.

...