我目前正在做一个项目，我正在添加一个新的休息界面。我编写了一个通用转换器，将响应转换为一些对象。现在我问自己是否应该将这些对象转换为让它们调用休息接口对象到一组新的对象，这将是我的模型。大多数时候，数据是相同的，但有时我会有不同的数据表示。例如，休息响应将有一个日期作为时间戳，但我的模型对象将有一个日期对象。
另一件好事是，如果我决定将其余接口更改为例如肥皂，我的客户端代码将仅依赖于模型对象，因此我只需要处理转换。一个缺点是，如果我必须更改某些内容，我需要在两个地方进行。
我不确定这个主题的最佳实践是什么。我还将剩余接口对象转换为模型对象（发送请求和响应的两种方式）。很高兴听到对此的一些想法，也许有人知道一些可以很好地解释这一点的资源。
听说过“过早优化”吗？一般来说，在设计您的应用程序时，我不会太在意性能。确保您创建的代码易于维护，易于在未来扩展，并且通常是面向未来的（例如，从 REST 切换到 SOAP 不会造成不必要的麻烦；这可能是一个比您想象的更现实的场景片刻）。你不应该仅仅因为你“认为”它可能有更好的性能，或者因为你认为“好的设计”可能有较差的性能，就选择一个糟糕的设计。
老实说，您计划每秒进行多少次 REST 调用，以及单个 REST 结果中有多少百万个对象？您可以创建最好的设计，如果您稍后发现性能瓶颈（浪费了太多的 CPU 时间、浪费了太多的内存等），那么您就开始优化这些瓶颈。如果你幸运的话，一开始就不会有瓶颈。如果您主要关心的是创建地球上见过的最快的代码段，那么您一开始就不会使用 Java，您可能会使用最低级别的 C 语言，在任何必须挤出最后一个的地方使用内联汇编CPU性能下降。
所以我不会在 REST API 之后对我的设计进行建模，我会按照我认为应该的方式对我的设计进行建模，以最简单的方式对应用程序的其余部分进行编码，然后编写一个导入器/导出器，将 REST 转换为我的设计和我的设计到 REST。如果您随后切换到另一种技术，如 SOAP，我只需要重写导入器/导出器，而不是整个应用程序。
不过也有例外：我个人不喜欢任何 OO 语言中的日期对象。时间戳是一个完美的日期表示恕我直言，它很容易使用（比较，添加/减去偏移量等）并且它具有非常低的内存开销（只是数字，通常是一个基元，甚至不是内存分配必要的）。因此，除非您需要日期对象，否则您无法按需要存储或显示此值，我会将时间戳保留为时间戳，如果您将来切换到 SOAP 并且它提供日期而不是时间戳，我宁愿将它们转换为时间戳在进口商中并在出口商中返回日期。然而，这只是我。