解耦胜过REST中的DRY吗？

我正在构建REST API，以公开现有Java API的大部分功能。这两个API都供我的组织内部使用；我不必为外部使用而设计。我对这两种API都有影响，但是正在实现REST。Java API将继续用于本地应用程序（不会“淘汰”），但是REST API将用于重大的新开发。

一些Java API类只是数据（带有属性，getter，setter的bean）。并且至少其中一些有意义的是通过REST API以某种形式（作为数据（将被编组为XML或JSON））进行传输。例如，一个存储有关服务器计算机信息的类。对于这些数据类，我面临以下选择：我是否...

1. 直接在REST API中公开原始Java类（或子类），或者
2. 专门为REST API创建新的数据传输类（DTO模式）？

无论哪种方式，我都会有REST数据传输类。问题是是要注释原始文件还是创建新的文件（可能是原始文件的副本）。可能还有其他选择，但我将主要关注这两个。

＃1的参数：

• 干（不要重复自己）
• 实施更快
• 升级REST API更容易

＃2的参数：

• 如果REST API需要与Java API分开版本，该怎么办？（这很有可能。）
• 如果Java数据类发生重大更改（例如，删除属性，添加行为或更改类层次结构）怎么办？（这也有可能。）

底线是，似乎在DRY（＃1）和去耦（＃2）之间进行了权衡。

我倾向于从＃1开始，然后如果出现问题，然后再转到＃2，请遵循不构建无法证明自己需要的敏捷指导。这是一个坏主意吗; 如果我认为我最终还是会从那里开始，我应该从＃2开始吗？

我的清单中是否缺少主要的论据/后果？

简单地说，好问题，解耦。这就是要走的路，您不想被Java版本所束缚。

在一种情况下，您不需要解耦：如果您的技术允许通过导线发送非特定于类型的对象，也就是说，如果您现在可以将当前的Java对象用作YAGNI，并用另一个您自定义的类型将是一个简单的插件，不会由于类型信息不断传递而破坏任何内容。因此，基本上，如果类型信息没有越线，您可以在此进行YAGNI。

请非常小心并注意，对Java版本的任何升级都不会更改任何这些对象。否则，现在就解耦，不用担心，我想这取决于您有多少时间选择。

但是，如果类型信息遍历您的协议，那么在底层Java类型更改时可能无法直接插入新类型，而可能会付出更大的努力。如果是这样，那么使用YAGNI现在意味着要累积技术债务和与您的基础技术有关的风险。

就我个人而言，我现在将解耦。

而且，DRY不会发挥作用，因为您没有编写底层代码，因此您不会重复编写代码，因此不会有遍地重复的错误之苦，这是DRY的主要关注点（以及一般的可维护性）您不会再遇到的问题，因为您无需重复维护）

＃1的主要论点是易于实现和升级，但是它满足您的要求吗？

在＃2的参数中，您指出Java API和REST API可能会独立更改。这意味着它们是单独的关注点，您不会通过使用单独的类来重复自己。仅仅因为两个事物看起来相同，并不意味着它们是相同的。

REST API不必遵循与数据模型相同的结构

实施REST时，请确保您正在创建直观的外部API，然后将其映射到内部数据模型类。这使您可以相互独立地进行更改，从而使API可以持续数十年。

因此，去耦是解决问题的方法。