问良好实践: REST作为接口层和业务层之间的接口？

EN

听起来你有两个问题，所以我的答案分为两部分。

首先，应该在接口层和业务层之间使用API吗？这当然是一种有效的方法，我在当前的项目中使用了这种方法，但是您必须自己决定它的好处，因为只有您知道您的项目。可能需要考虑的最大因素是，是否会有足够多的不同客户端访问业务层，以证明在开发API时所做的额外开发工作是合理的？这通常意味着超过一个客户端，因为当您发布更改或bug修复时，拥有API的好处将是显而易见的。还要考虑额外的复杂性、额外的代码维护开销以及分离接口和业务层可能带来的任何好处，例如增加的可测试性。

其次，如果您实现了一个API，您应该使用REST吗？REST是一种体系结构，它与API一样，说明了应用程序的其余部分是如何开发的。在API级别定义没有转换到业务层的资源是没有好处的。Rest往往是一种很好的方法，当您希望很多人能够使用您的API进行开发时(例如，NetFlix )。在我当前的项目中，我们采用了基于HTTP的XML，因为我们不需要Rest通常提供的好处(或者SOAP )。

一般来说，经验法则是实现最简单的解决方案，而不是将自己编码到一个角落，而是为今天的需求而不是明天的需求开发。

克里斯

如果要通过Internet从本地客户端访问Web服务层，您肯定需要一个Web服务层。

实现这一点显然有很多方法和解决方案，但是我认为正确的体系结构准则是在服务器上有一个定义良好的服务接口，由客户机上的网关访问。然后，您将使用POCO DTO的(普通旧DTO)在端点之间进行通信。DTO的主要目的是通过连接提供web服务的最佳表示，它还允许您避免不得不处理序列化，因为它应该由客户端网关和服务接口库透明地处理。

它实际上取决于如何扩大您的项目/应用程序，这取决于您是否希望完成将您的DTO映射到客户端和服务器域模型的工作。对于大型应用程序，一般的方法是在客户机上将DTO映射到您的UI模型，并将您的UI视图绑定到它。在服务器上，您将映射您的DTO到您的域模型，并根据服务的实现将其持久化。

REST是一种体系结构模式，对于小型项目，我认为这是一种额外的开销/复杂性，因为与以RPC /文档为中心的web服务相比，它不太适合开发。换句话说，REST的一般思想是围绕资源开发您的服务。这些资源可以有多个表示，web服务应该根据HTTP客户端所指示的首选内容-类型(即在HTTP接受标头中)提供这些表示。您的web服务的规范urls也应该在逻辑上形成(例如/customers/reports/1，而不是/GetCustomerReports?Id=1)，您的web服务将在每个响应中返回“客户端可以输入的有效状态”列表。基本上，REST是一种很好的方法，它促进了松散耦合的体系结构和重用，但是，与标准的RPC/基于文档的web服务相比，要“坚持”需要付出更多的努力，而这些服务的好处不大可能在小型项目中显现。

如果您仍然在评估您应该使用的web服务技术，您可能需要考虑使用我的开源web框架，因为它是针对这个任务进行优化的。您用来定义web服务接口的DTO可以在客户机上重新使用(通常情况不是这样)，以提供一个强类型的接口，其中所有的序列化都是为您进行的。它还具有额外的好处，使您创建的每个web服务都可以由SOAP1.1/1.2、XML和JSON web服务自动调用，而不需要任何额外的配置，因此您可以为每个客户端场景选择最优的端点，即本机桌面或Web应用程序等。

我最近基于J2EE6的偏好是在会话bean中实现业务逻辑，然后根据需要添加SOAP和RESTful web服务。添加胶水来实现围绕这些会话bean的web服务非常简单。这样，我就可以提供对特定用户应用程序最有意义的服务。