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 ...
- exposer la classe Java d'origine (ou une sous-classe) directement dans l'API REST, ou
- 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?