Comment implémenter backend d'api avec plusieurs versions

Question

J'utilise Django pour implémenter une API de repos privée et je ne sais pas comment gérer différentes versions de l'API sur le backend. Par exemple, si j'ai 2 versions de l'API, à quoi ressemble mon code? Devrais-je avoir différentes applications qui traitent une version différente? Les différentes fonctions devraient-elles gérer différentes versions? Ou devrais-je simplement utiliser si des déclarations pour quand une version diffère d'une autre?

Je prévois d'indiquer la version dans l'en-tête.

Merci

Answer 1

Vous ne ont pas besoin d'API REST version. Avec REST, la gestion des versions se produit au moment de l'exécution, soit par le biais de ce que l'on pourrait appeler les règles d'extension de la charge utile "must-ignore", soit par la négociation de contenu.

'must-ignore les règles d'extension de charge utile' font référence à un aspect que vous intégrez dans la conception de vos messages. "Must-ignore" signifie qu'un logiciel qui traite un message du format donné doit ignorer toute construction syntaxique inconnue. C'est ce que nous savons tous du HTML et ce qui permet d'insérer toutes sortes de balises fantaisistes dans une page HTML sans l'étouffement de l'analyseur. 'Must-ignore' vous permet de faire évoluer les capacités de votre service en ajoutant des éléments à ce que vous envoyez déjà sans tenir compte des clients qui ne comprennent que les anciennes versions.

La négociation de contenu fait référence au mécanisme intégré de négociation de la représentation réelle que le serveur envoie à un client au moment de l'exécution. Le scénario typique est le suivant: Les clients envoient l'en-tête Accept dans la demande pour annoncer ce dont ils sont capables et les serveurs sélectionnent la représentation à renvoyer en fonction de ces capacités. Mais il existe également des variantes de ce thème (voir ici pour plus de détails: http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html).

La négociation de contenu permet des changements incompatibles, ce qui signifie que je peux faire évoluer mon service pour pouvoir envoyer des versions anciennes et nouvelles incompatibles et, en fonction de l'en-tête Accept, mon service enverra le service approprié.

Conclusion: avec les deux approches, votre API reste telle quelle. Pas besoin de faire de versionnement au niveau de l'API - surtout pas l'inclusion souvent suggérée (mais totalement erronée) des identifiants de version dans les URI (souvenez-vous, vous faites REST ici, pas SOAP!)