我正在考虑我计划构建的 Web 应用程序的架构，我发现自己对应用程序的核心部分思考了很多。例如，由于我想创建一个 android 应用程序来访问它，所以我已经在考虑拥有一个 API。
鉴于我从一开始就希望为我的应用程序提供一个外部 API，使用该 API 作为接口层（Web）和我的应用程序的业务层之间的接口是一个好主意吗？这意味着即使我的应用程序的主界面也可以通过 API 访问数据。这种方法的缺点是什么？性能？
更笼统地说，如果一个人正在构建一个可能需要以不同方式访问的 Web 应用程序，将 API（Web 服务）作为接口之间的接口是一种好的架构设计吗？层和业务层？ REST 是一个很好的“工具”吗？
【问题讨论】：
标签： api rest architecture
听起来你有两个问题，所以我的答案分为两部分。
首先，你应该在接口层和业务层之间使用 API 吗？这当然是一种有效的方法，我在当前的项目中正在使用这种方法，但您必须自己决定好处，因为只有您知道您的项目。可能要考虑的最大因素是是否会有足够多的不同客户端访问业务层来证明开发 API 的额外开发工作是合理的？通常这仅仅意味着超过 1 个客户端，因为当您发布更改或错误修复时，拥有 API 的好处将显而易见。还要考虑增加的复杂性、额外的代码维护开销以及分离接口和业务层可能带来的任何好处，例如提高可测试性。
其次，如果你实现一个 API，你应该使用 REST 吗？ REST 是一种体系结构，它说明了应用程序的其余部分是如何开发的，就像它说明 API 一样。在 API 级别定义不转换为业务层的资源是不好的。当您希望很多人能够针对您的 API 进行开发（例如 NetFlix）时，休息往往是一种好方法。在我当前的项目中，我们选择了基于 HTTP 的 XML，因为我们不需要 Rest 通常提供的好处（或者 SOAP）。
一般来说，经验法则是实施最简单的可行解决方案，不要将自己编码成一个角落，为今天的需求而不是明天的需求而开发。
克里斯
【讨论】：
如果您要通过 Internet 从本地客户端访问它，您肯定需要一个 Web 服务层。
显然有很多方法和解决方案可以实现这一点，但是我认为要遵循的正确架构指南是在服务器上具有明确定义的 服务接口，该接口可通过 网关访问 在客户端。然后，您将使用 POCO DTO's（普通旧 DTO's）在端点之间进行通信。 DTO 的主要目的是通过网络提供 Web 服务的最佳表示，它还允许您避免处理序列化，因为它应该由客户端网关和服务接口库透明地处理。
这实际上取决于您的项目/应用程序的规模如何，是您是否想要努力将您的 DTO 映射到客户端和服务器域模型。对于大型应用程序，一般方法是在客户端上将您的 DTO 映射到您的 UI 模型，并将您的 UI 视图绑定到它。在服务器上，您可以将您的 DTO 映射到您的域模型，并根据服务的实现将其持久化。
REST 是一种架构模式，对于小型项目，我认为它会带来额外的开销/复杂性，因为与 RPC / 以文档为中心的 Web 服务相比，它在程序化方面不太合适。简而言之，REST 的总体思路是围绕资源 开发您的服务。这些资源可以有多种表示形式，您的 Web 服务应根据您的 HTTP 客户端（即在 HTTP ACCEPT HEADER 中）指示的首选 Content-Type 提供这些表示形式。您的 Web 服务的规范 url 也应该在逻辑上形成（例如 /customers/reports/1 而不是 /GetCustomerReports?Id=1），并且您的 Web 服务理想情况下会返回“您的客户可以输入的有效状态”列表回复。基本上 REST 是一种很好的方法，可以促进松散耦合的架构和重用，但是与标准的基于 RPC/文档的 Web 服务相比，它需要更多的努力来“坚持”，后者的好处在小型项目中不太可能显现出来。
如果您仍在评估应该使用哪种 Web 服务技术，您可能需要考虑使用我的 open source web framework，因为它已针对此任务进行了优化。您用来定义 Web 服务接口的 DTO 可以在客户端上重用（通常情况下并非如此），以提供强类型接口，所有序列化都为您完成。它还具有额外的好处，即使您创建的每个 Web 服务都可以由 SOAP 1.1/1.2、XML 和 JSON Web 服务自动调用，而无需任何额外配置，因此您可以为每个客户端场景选择最佳端点，即本机桌面或Web App等
【讨论】：
我最近基于 J2EE6 的偏好是在会话 bean 中实现业务逻辑，然后根据需要添加 SOAP 和 RESTful Web 服务。添加胶水以围绕这些会话 bean 实现 Web 服务非常简单。这样我就可以提供对特定用户应用程序最有意义的服务。
【讨论】：
我们很幸运在一个项目上做了这样的事情。我们的网络服务主要做标准的内容管理，读取（GET）到写入（PUT、POST、DELETE）的比例很高。所以如果你的逻辑层是相似的，这是一个非常合理的考虑方法。
在一个例子中，我们有一个 Android 上的视频播放器应用程序（摩托罗拉 Droid、Droid 2、Droid X，...），它由云中的一组 REST Web 服务支持。这些公开视频点播内容目录，启用视频会话设置和拆除，处理书签，等等。 REST 在这方面做得很好。
对我们而言，REST 的主要优势之一是可扩展性：由于 RESTful GET 响应可以缓存在 HTTP 基础架构中，因此可以从同一个 Web 应用程序为更多客户端提供服务。
但是 REST 似乎不太适合某些类型的业务逻辑。例如，在一种情况下，我将日常维护操作封装在 Web 服务 API 后面。使用什么动词并不明显，因为这个操作从远程源读取数据，用它对本地数据库进行大量创建和更新，然后删除旧数据，然后告诉外部系统做事。所以我决定把它做成一个 POST，让 API 的这一部分成为非 RESTful。尽管如此，通过在此操作之上添加一个 Web 服务层，我们可以在计时器上运行每日脚本，运行它以响应某些外部事件，和/或让它作为更高级别工作流的一部分运行。
由于您使用的是 Android，请查看 Java Restlet Framework。有一个 Restlet edition supporting Android。几年前，Overstock.com 的工程总监对我赞不绝口，他告诉我们的一切都是真的，这是一个非常出色的框架，让事情变得简单。
【讨论】：
当然，可以使用 REST。但首先问问自己，这有意义吗？ REST 和其他工具一样是一种工具，虽然很好，但并不总是适合每个钉子的最佳锤子。以 RESTfully 方式构建此接口的优势在于，IMO 将来会更轻松地为这些数据创建其他用途——也许您还没有想到。如果您决定使用 REST API，您的下一个问题是，它会说什么语言？我发现 AtomPub 是流程/应用程序交换信息的好方法 - 它非常可扩展，因此您可以添加许多自定义元数据，但仍然可以使用任何 Atom 库轻松解析。微软在其云 [Azure] 平台中使用 AtomPub 在数据生产者和消费者之间进行对话。只是一个想法。
【讨论】：