codage du versionnement des appareils mobiles pour le serveur REST Api

Question

Nous avons une API reposante sur HTTP. Parmi les autres clients, nous avons également des clients d'appareils mobiles (par exemple, iphone). Le problème est qu'il existe plusieurs applications iPhone dans différentes versions (1.0, 2.0). Parce qu'ils sont distribués, nous n'avons aucun contrôle sur la version de l'application qui nous appelle.

Pour identifier l'application version sur côté serveur je vois les options suivantes:

dispositif
1. devez ajouter le paramètre d'URL (par exemple /foo?iphone-app-version=1.0): Un peu dégueu, mais bon chose est que je peux le voir toujours sur server-logs (URL est toujours connecté)
2. nous authentifions api-clients avec digestion HTTP. Nous pourrions encoder la version de l'application à l'intérieur du nom d'utilisateur (par exemple iphone_1_0): C'est une bonne chose qu'il soit enregistré dans les journaux du serveur, mais ne fonctionne que pour les ressources qui sont exposées en tant que digest HTTP.
3. Le périphérique doit utiliser un en-tête HTTP personnalisé, par ex. X-IPHONE-APP-VERSION: À mon avis l'approche la plus propre, mais nous ne consignons pas les en-têtes HTTP dans les journaux du serveur (pour le bruit du journal, il est désactivé). Donc, l'analyse plus tard n'est pas possible.

Avez-vous une approche préférée ou d'autres alternatives?

EDIT: Avec les versions précédentes, je ne parle pas d'api-versioning/content-negotiation. C'est la version de l'appareil mobile.

Answer 1

J'ai décidé de créer un X-xxx-USER-AGENT personnalisé. La raison principale pour décider contre plus standard "User-Agent" est qu'il est déjà "pollué" avec la bibliothèque http-client ou des informations de périphérique mobile. Un X-xxx-USER-AGENT personnalisé est plus facile à analyser pour le serveur et n'interfère pas la bibliothèque http qui le définit souvent et pourrait remplacer une entrée personnalisée.

Answer 2

Vous pouvez utiliser Accept-Header pour permettre à un client de déclarer ses capacités en identifiant les versions des types de support qu'il prend en charge. par exemple.

application mobile ne:

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

Lorsque vous introduisez de nouvelles fonctionnalités qui vous ne pouvez pas rétrocompatible dire aux nouveaux clients mis à jour à envoyer,

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

Ensuite, votre serveur connaît les capacités du le client à qui il s'adresse. Vous pouvez également obtenir les nouveaux clients de le faire:

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

De cette façon, vous pouvez migrer vos ressources du serveur vers le nouveau format lentement. Si les points d'extrémité délivrent application/vnd.acme.fooappV1+xml, le client revient à l'ancienne méthode. Si les points de terminaison renvoient application/vnd.acme.fooappV2+xml, le nouveau code peut prendre le relais.

En utilisant cette approche, aucun URI n'a besoin d'être modifié, de sorte que les signets et les statistiques restent valides. La migration vers un nouveau format peut se faire de manière incrémentielle avec le temps et le support pour les anciens clients peut être progressivement éliminé.