J'écris une API Rest et je me demande comment gérer au mieux la prise en charge des différentes versions. Par cela, je ne veux pas dire comment définir un URI comme V2 ou V3, mais plutôt comment structurer le code étant donné qu'il devrait:
- Prend en charge plusieurs versions en même temps, par exemple. Les URI V1 & V2 & V3 doivent être en direct en même temps. Je retirerais V1 lorsque disons que V4 arrive afin de limiter le montant pris en charge à un moment donné.
- Évitez autant de duplication de code que possible
- Facilitez l'ajout de modifications incessantes à une version, sans impact sur les autres versions
Il semblerait qu'il existe peu d'approches possibles:
Utilisez Git pour contrôler les versions, avec une branche pour les différentes versions (et les anciennes versions n'ayant essentiellement aucun nouveau travail de développement). Cela signifierait aucune duplication de code car seule la dernière version est dans le code, mais les versions précédentes devraient fonctionner avec la nouvelle version de la base de données jusqu'à ce qu'elles soient retirées.
Dupliquer le code afin que chaque version soit gérée dans la même application et ait un chemin de code totalement séparé, mais cela signifierait beaucoup de duplication
Réutilisez beaucoup de code dans les versions, mais cela rendrait la maintenance plus difficile, car la modification d'une version est plus susceptible d'avoir un impact sur une version précédente
Existe-t-il une meilleure pratique pour résoudre ce problème, car toutes les options semblent avoir leurs propres problèmes?
la source
Réponses:
Faites ceci:
mais ne cassez pas les versions précédentes.
Vous devriez avoir des tests qui vérifient que toutes les versions prises en charge fonctionnent correctement. Si vous n'avez pas ces tests, vous devez d'abord les créer pour couvrir tout code que vous modifiez.
la source
Une combinaison de l'utilisation des branches de publication GIT (ou fork chaque version dans un référentiel séparé) pour prendre en charge et maintenir les anciennes versions d'API et éventuellement avoir du code réutilisable qui peut être partagé en tant que dépendance, comme une bibliothèque commune, est très probablement le moyen aller. Ainsi, chaque version d'API serait un artefact déployable séparément. Cela permet une flexibilité pour que, par exemple, l'API V1 puisse dépendre des communs V1, tandis que les API V2, V3, V4 peuvent dépendre des communs V2. Ce serait le plus simple et le plus propre du point de vue du développement, car votre base de code ne se multiplie pas avec chaque nouvelle version, mais chaque version est isolée dans son propre projet / base de code et ne se préoccupe que d'elle-même.
Une autre raison de déployer des artefacts distincts est qu'il peut y avoir des préoccupations transversales comme un mécanisme de sécurité, ou des cadres / bibliothèques comme votre cadre d'injection de dépendances qui pourraient changer dans les versions plus récentes de l'API et créeraient beaucoup de difficultés à prendre en charge les anciennes API s'ils tous vivent dans la même base de code (et Classloader à l'exécution, si c'est Java).
Chaque approche, que ce soit une branche par version ou une base de code dupliquée monolithique, aura toujours le problème d'un point d'intégration commun (comme la base de données ou un schéma de cache distribué) qui doit changer. Les anciennes versions d'API peuvent nécessiter une sorte de maintenance pour fonctionner avec ces modifications, ou l'introduction d'autres outils (comme les vues de base de données) pour faciliter la compatibilité. Cela peut être une difficulté inévitable selon la nature de vos changements.
la source
Je ne sais pas à quel point les résultats sont différents de vos versions d'API, mais vous pourriez avoir une couche de compatibilité au milieu qui peut basculer entre les versions et combler les lacunes ou traduire les données.
Cela étant dit - cela ne fonctionne généralement jamais un à un - donc une conception de type commutateur ou machine d'état m'a aidé à résoudre ce problème.
la source