传统的Web应用程序和RESTful API

如今，当我们构建Web应用程序时，将所有功能公开为RESTful API，然后自己使用它是一种最佳实践。这通常与使用繁重的javascript的丰富前端配合使用，例如Angular / Ember / Backbone / React。

但是沉重的前端似乎不是一个很好的默认值–需要概念上沉重的javascript框架开销的应用程序实际上并不是绝大多数。网络虽然复杂得多，但仍然不仅仅是单页应用程序。更不用说，如果您正在编写静态类型的后端，则可能需要一个专用的javascript团队（不一定是个好主意，尤其是在小型公司/初创企业中），或者您必须在其中编写……不太令人愉快语言。老实说，我的浏览器到处都在使用所有不必要JavaScript，但这是一个独立的故事。

让自己使用自己的RESTful API的另一种选择是拥有一个“ Web”模块，该模块调用您的“后端”模块。这可能是一个好主意，尤其是在您拥有不同专业的不同团队的情况下，但是为了分离而引入如此多的通信开销似乎至少应该在操作前三思。更不用说现实中的发布周期通常是捆绑在一起的，因为您需要付出额外的努力才能使“ Web”和“后端”保持适当的同步（“ Web”不请求“后端”尚未提供的服务，或者“后端”未提供“网络”不期望的修改后的响应模型）。

正如我对整体的辩护一样，我显然倾向于整体应用。我不会重复另一篇文章，但是我的想法是，即使应用程序在单个运行时（例如JVM）中运行，也可以是模块化的。有了您的“ Web”软件包，有了您的“服务”软件包，它们可以独立开发，甚至可以作为单独的（子）项目编译成一个可部署的工件。

因此，如果您想要一个传统的Web应用程序-请求/响应，一点点的ajax，但又没有繁琐的javascript幻想，也没有架构开销，并且仍然想将服务公开为RESTful API，该怎么办？

您的Web层-控制器，使用来自表单提交的请求参数并使用模板引擎呈现响应-通常与您的服务层通信。因此，对于您的Web层，服务层只是一个API。它通过JVM内部的方法调用来使用它。但这不是使用服务层的唯一方法。诸如Spring-MVC，Jersey等框架允许注释任何方法并将其作为RESTful服务公开。通常，服务层不公开为Web组件，但可以公开。因此–您通过方法调用使用了服务层API，其他所有人都通过HTTP使用了它。相同的定义，相同的输出，相同的安全性。而且，您不需要单独的传递层即可拥有RESTful API。

从理论上讲，这听起来不错。在实践中，将方法变成端点的注释可能会带来问题-序列化/反序列化是否正常工作，标题是否正确处理，身份验证是否正确。而且，如果仅在单个JVM中使用方法，您将不会知道这些方法不起作用。是的，您会知道它们在业务逻辑方面可以正常工作，但是启用RESTful的部分可能有所不同。

这就是为什么您需要全面接受验收测试的原因。诸如黄瓜/ JBehave之类的东西可以测试所有暴露的端点。这样，您将确保RESTful方面和业务逻辑均正常运行。无论如何，实际上实际上是应该存在的东西，因此没有开销。

另一个问题是您可能希望将API与主应用程序分开部署。 https://yoursite.com和https://api.yoursite.com。您可能只希望在一个集群中运行API，而在另一个集群中运行您的应用程序。没问题–您可以使用配置开关和应用程序简单地禁用“ Web”部分，并多次部署相同的工件。

我不得不承认我还没有尝试过这种方法，但是它看起来像是一种简单的方法，仍然可以正确覆盖所有用例。