问题描述
假设我有一个服务，它只是一个 REST-API。这个rest api提供了一些数据。
据我所知，这是有道理的，我可以将从此服务发送和发送到此服务的数据封装到 DTO's 中。这完全是有道理的，因为您将拥有一些业务对象，但通常您需要以某种方式序列化它们。因此，据我所知，这将是一种普遍接受且知道将其抽象化的方法。
然后通过 REST-API 发送此 DTO。关于服务器端，它的接缝非常简单，有一些提供数据或接收数据的控制器，我在那里没有看到任何问题（至少现在是这样）。
关于我的问题。在客户端有一些对象，它们将访问这个 API，这个对象在我的实现中包含一个 http 客户端（不确定我是否可以将它们与这个对象分离）并且它还包含访问 api 的方法。因此，以一种或另一种方式，抽象出 http 客户端的使用并访问 API。
您如何命名这些访问 API 的对象？
我现在将它们命名为 XXXManager/XXXHandler/...，但这些名称感觉远非通用，我觉得必须为此制定一些约定或模式？将它们命名为 XXXService 也感觉不完全正确，因为服务对我来说就像服务器端的部分，这个对象正在访问服务。
那么您将如何命名此类对象，是否有一些更深层次的模式来处理此类服务/api 访问器？
解决方法
适用于此处的模型/模式是经典的 layered architecture，其工作方式如下：
-
HttpClient 应该包裹在一个类（让我们将其命名为
ApiClient）周围，该类公开用于访问 REST API 的方法。在每个方法中，httpClient 用于执行 HTTP 调用。 -
有一层使用
ApiClient并应用自己的业务逻辑的服务/管理器类。 -
有一层 UI 组件，这些组件还注入服务/管理器以获取数据并将其呈现在 UI 上。
通过这种方式，您可以将层解耦，从而提高代码的可扩展性和可测试性。
命名在某种程度上取决于您拥有的客户端实现/框架的类型。
如果您有 Web 前端客户端，那么名称 TransactionService 会告诉我该类与某些外部事务服务对话（Service 不是与服务器端组件相关的命名）。
例如，此命名模型适用于 Angular。
,Patterns of Enterprise Application Architecture 建议使用 Gateway，但我会选择 Client。