Le découplage l'emporte-t-il sur SEC en REST?

Je construis une API REST pour exposer la plupart des fonctionnalités d'une API Java existante. Les deux API sont à usage interne au sein de mon organisation; Je n'ai pas à concevoir pour un usage externe. J'ai une influence sur les deux API mais j'implémente celle REST. L'API Java continuera d'être utilisée pour les applications locales (elle n'est pas "retirée"), mais l'API REST sera utilisée pour de nouveaux développements importants.

Certaines classes d'API Java sont simplement des données (beans avec propriétés, getters, setters). Et au moins certains d'entre eux ont un sens à transmettre (sous une forme) sur l'API REST en tant que données (qui seront rassemblées en XML ou JSON). Par exemple, une classe qui stocke des informations sur une machine serveur. Je suis confronté au choix suivant pour ces classes de données: Dois-je ...

1. exposer la classe Java d'origine (ou une sous-classe) directement dans l'API REST, ou
2. faire une nouvelle classe de transfert de données (modèle DTO) spécifiquement pour l'API REST?

Dans tous les cas, j'aurai des classes de transfert de données REST; la question est de savoir s'il faut annoter les originaux ou en créer de nouveaux (qui peuvent être des copies proches des originaux). Il peut y avoir d'autres choix, mais je me concentrerai principalement sur ces deux-là.

Arguments pour # 1:

• SEC (ne vous répétez pas)
• Mise en œuvre plus rapide
• Mise à niveau de l'API REST plus facile

Arguments pour # 2:

• Que faire si l'API REST doit être versionnée séparément de l'API Java? (C'est assez probable.)
• Que se passe-t-il en cas de modifications importantes des classes de données Java telles que la suppression de propriétés, l'ajout de comportement ou des modifications de la hiérarchie des classes? (C'est également quelque peu probable.)

En bout de ligne, cela semble être un compromis entre DRY (# 1) et découplage (# 2).

Je penche pour commencer avec le n ° 1, puis si des problèmes surviennent, passer au n ° 2 plus tard, en suivant la directive agile de ne pas construire ce dont vous ne pouvez pas prouver que vous avez besoin. Est-ce une mauvaise idée; devrais-je commencer par # 2 si je pense que je pourrais y arriver de toute façon?

Y a-t-il des arguments / conséquences majeurs manquants dans mes listes?

Bonne question, simplement, découpler. C'est la voie à suivre ici, vous ne voulez pas être lié à la version de java.

Il n'y a qu'un scénario que vous ne dissociez pas: si votre technologie permet d'envoyer des objets non spécifiques au type sur le câble, c'est-à-dire, si vous pouvez utiliser les objets java actuels maintenant comme YAGNI, et le remplacement par un autre le type que vous avez personnalisé sera un simple drop-in qui ne cassera rien en raison des informations de type passant sur le fil. Donc, fondamentalement, si les informations de type ne traversent pas le fil, vous pouvez YAGNI à ce sujet.

Soyez très prudent et vigilant: toute mise à niveau de votre version java ne changera aucun de ces objets. Sinon, découplez maintenant et ne vous inquiétez pas, je suppose que cela dépend du temps dont vous disposez si vous avez le choix.

Cependant, si les informations de type traversent le fil dans votre protocole, un ajout plat de nouveaux types lorsque les types de java sous-jacents changent peut ne pas être possible et peut plutôt représenter un effort plus important. Si tel est le cas, devenir YAGNI signifie désormais accumuler des dettes techniques et des risques liés à votre technologie sous-jacente.

Personnellement, je découplerais maintenant.

De plus, DRY ne joue pas là-dedans parce que vous n'avez pas écrit les pièces sous-jacentes donc vous ne dupliquez pas de code et donc vous n'aurez pas à répéter les douleurs des bogues, ce qui est la principale préoccupation de DRY (et la maintenabilité générale problèmes que vous n'aurez pas non plus car vous n'avez pas de doublons à maintenir)

Les principaux arguments pour le n ° 1 sont la facilité de mise en œuvre et les mises à niveau, mais cela répond-il à vos besoins?

Dans vos arguments pour # 2, vous indiquez que l'API Java et l'API REST peuvent probablement changer indépendamment. Cela signifie qu'il s'agit de préoccupations distinctes et que vous ne vous répétez pas en utilisant des classes distinctes. Ce n'est pas parce que deux choses se ressemblent qu'elles ne sont pas identiques.

Votre API REST n'a pas à suivre la même structure que votre modèle de données

Lors de l'implémentation de REST, assurez-vous que vous créez une API externe intuitive, puis mappez-la à vos classes de modèle de données internes. Cela vous permet de changer chacun indépendamment des autres, ce qui conduit à des API qui peuvent durer des décennies .

Par conséquent, le découplage est la voie à suivre ici.