如何将 Web 服务与 html 响应控制器分离？答案

【问题标题】：How to decouple web service from the html response controllers?如何将 Web 服务与 html 响应控制器分离？
【发布时间】：2014-06-26 10:30:48
【问题描述】：

我正在使用 Spring MVC 构建一个 Web 应用程序，其长期目标是将其构建为一个 Web 服务，供多个客户端（Web、Android、iPhone 等）使用，但为了构建一个快速原型，我我正在寻找构建将用作 html 响应的 Web 应用程序（由于缺乏前端 MVC 框架的专业知识）。计划是稍后将 Web 应用程序转变为由 Web 服务 api 提供服务的单页应用程序。

我关心的是我应该采用两种方法中的哪一种：

首先通过提供基于 JSON 的 API 的一个应用程序和另一个将与 Web 服务交互的 Web 应用程序（单独部署）公开控制器，从而构建一个 Web 服务。这使得我们的网络服务可以被其他客户使用。
第二种方法可能不是通过控制器公开我们的 api，我们可以在控制器下方有另一层，这将为 apis 奠定基础，然后我们公开一组控制器以使用服务器端模板处理。稍后我们可以公开另一组控制器，它们将使用地面 API 并将其转换为 Web 服务 API。这些控制器可以映射到单独的 url，或者可以通过为响应内容类型设置一些参数或设置接受标头来使用相同的 url。

请告诉我这两种方法中哪一种更好？ first 的优点是一旦我们构建了 Web 服务，它就可以立即被其他客户端使用。另一方面，第二种方法让我们优化部署两个不同应用程序的带宽和开销。

【问题讨论】：

标签： java web-services spring-mvc

【解决方案1】：

我不喜欢让控制器调用控制器的想法（我相信这就是您在 #2 中的意思）。我也喜欢代码职责分离的想法。如果您希望您的 WS API 真正与您的客户端分开，那么您的代码也应该分开。我也认为这是一个更好的设计，因为它

让您专注于 WS 代码中的 WS 事物和 UI 代码中的 UI 事物。
使两者的代码库更易于维护，因为它们中的代码（可以说）更少，因为它们只包含那里需要的部分。
允许您根据什么对 WS 应用程序最有利做出特定于 WS 端的决策，并根据什么对 UI 应用程序最有利而针对 UI 端做出决策，而不必妥协，因为它们是在臀部连接的。

不过，有些人可能会争辩说您可能会增加很多复杂性。但是，我认为职责分离始终是一件好事，并且可以提供更清洁、更好的解决方案。

【讨论】：

我不是说从控制器调用控制器，而是为 UI 和数据编写单独的一组控制器，而共同的基础工作（业务逻辑）可以在控制器下面的层中执行（比如服务层）。此外，虽然我知道将两个代码库分开是个好主意，但它会导致更高的延迟和更多的代码，因为每次您必须从 ui 应用程序向 Web 服务应用程序发出 http 请求。
我不知道您是否可以提出更高延迟的论据，但您绝对可以提出更高内存占用的论据，因为两个单独的部署意味着共享代码被加载两次。然而，有人可能会争辩说，在一个好的 MVC 设计中，“V”部分无论如何都应该是相当孤立的。还要考虑到 UI 代码很可能是用一种完全不同于其他语言的语言编写的，这一切都取决于您打算如何部署事物以及您认为瓶颈将在哪里。