Ajout de champs à un WebService

Question

J'ai un service SOAP qui expose une méthode

TradeDetail getTradeDetail() 

magasins TradeDetail 5 champs, numéro de transaction, les dates etc

Je dois ajouter quelques champs à TradeDetail. Je veux garder la compatibilité ascendante (pendant un certain temps) et il semble que mes options sont limitées à la création d'une nouvelle classe avec les champs supplémentaires

TradeDetail2 getTradeDetail2() 

Maintenant cela va fonctionner - je l'ai fait avant. Mais y a-t-il d'autres solutions que les gens ont utilisées?

E.g.

• Modifiez fondamentalement TradeDetail2 pour ajouter des paires de valeurs de nom.
• Hériter TradeDetail2 de TradeDetail, cela réduirait le code, mais augmenter le couplage
• XML de retour ou JSON au lieu

je serai en mesure de prendre sa retraite l'interface originale assez rapidement de sorte que le code va se nettoyer et extra TradeDetail2 ne durera pas éternellement!

grâce

Answer 1

Je sympathise - certains de mes webservices sont criblés de myMethod(), myMethod2(), etc myMethod3() simplement parce que je devais ajouter quelques nouveaux champs.

Serait-il logique de conserver le nom de la méthode et de créer un nouveau point de terminaison pour chaque version de votre API à la place? par exemple:

• http://my.domain.com/servicename/v1
• http://my.domain.com/servicename/v1.1
• http://my.domain.com/servicename/v1.5
• http://my.domain.com/servicename/v2

Ensuite, vos noms de méthode rester raisonnable, quel que soit le nombre des changements à venir que vous devez faire. Toutes les applications utilisant votre webservice auraient probablement besoin d'être réécrites et/ou reconstruites contre un nouveau WSDL afin de profiter des nouveaux champs, alors pourquoi ne pas les avoir réécrites/reconstruites avec la nouvelle API v1.1? . Je trouve que cela aide également lors de la communication avec les propriétaires/développeurs des applications utilisant votre service - par exemple, "La version [ancienne] de notre API webservice ne sera plus supportée après le [date], veuillez vous assurer que vous utilisent au moins la version [nouveau] "

Answer 2

Cet article Best practices for Web services versioning peut être utile.

Answer 3

C'est pourquoi je préfère avoir un contrôle complet sur XML vers Object mapping, afin de pouvoir séparer le modèle de l'interface XML. Dans votre cas, je voudrais simplement ajouter de nouveaux champs à TradeDetail, et les considérer comme "optionnels" pour la rétrocompatibilité.Ce serait l'exemple XML-> mapping objet pour TradeDetail dans le cadre de mon équipe utilise, écrit pour votre interface:

// this would go into my client endpoint class 
public TradeDetail getTradeDetail() { 
    Element requestRoot = new Element("GetTradeDetail"); 
    Element responseRoot = invokeWebServiceAndReturnJdomElement(requestRoot); 
    return mapTradeDetail(responseRoot); 
} 

// this would go into my client XO mapping class 
public TradeDetail mapTradeDetail(Element root) { 
    TradeDetail tradeDetail = new TradeDetail(); 
    tradeDetail.setField1 = fetchString(root, "/GetTradeDetail/Field1"); 
    tradeDetail.setField2 = fetchInteger(root, "/GetTradeDetail/Field2"); 
    tradeDetail.setField3 = mapField3(root, "/GetTradeDetail/Field3"); 
    tradeDetail.setField4 = fetchString(root, "/GetTradeDetail/Field4"); 
} 

Ce type de client ne tiendrait pas compte de nouveaux domaines, étant ainsi compatible avec la nouvelle version du protocole, jusqu'à ce que je ajouter quelque chose comme ça à la fin de cette même méthode dans la version 2:

if (fetchXPath(root, "/GetTradeDetail/Field5") != null) { 
    // so we're talking with server which speaks new version of protocol 
    tradeDetail.setField5 = fetchString(root, "/GetTradeDetail/Field5"); 
} 

serveur travaillerait avec un code similaire, vérifier éventuellement la version client, et la cartographie des champs supplémentaires que si le client prend en charge la nouvelle version du protocole. À mon avis, le client devrait être écrit pour que quelques champs supplémentaires ajoutés au protocole ne cassent pas le client - Je n'ai pas le luxe d'être en panne simplement parce que le fournisseur en amont a ajouté de nouvelles fonctionnalités et ne m'a pas informé à propos de ça. Si le fournisseur change les champs obligatoires existants, bien sûr, le client a besoin de modifications. C'est pourquoi le fournisseur en amont devrait version protocole et soutenir l'ancienne version pendant au moins quelques mois.