完全分离后端和前端Web应用程序并允许它们与（JSON）REST API通信是正常的设计吗？

我正在创建新的业务Web应用程序，并且想要实现：

使用各自领域的最佳技术。我想要具有可靠ORM的可靠后端框架。我想要最先进的SPA（单页应用程序）框架，并为前端应用程序使用最新的HTML和Javascript功能
公开后端实体和业务服务以供不同类型的应用程序使用，例如，Web应用程序，移动（Android）以及可能的其他类型（智能设备等）

因此，为了满足这两个要求，我倾向于将我的应用程序完全隔离在后端和前端应用程序中，并使用REST API（JSON）来组织它们之间的通信。这是合理的方法吗？

这种分离并不是显而易见的设计解决方案，因为许多Web应用程序技术都集成了视图层，其中服务器端应用程序或多或少地控制视图的生成并部分处理视图的响应（例如，带有视图层的SpringMVC，带有视图的PHP Yii Java JSF / Facelets层将其组件的状态完全保存在服务器上）。因此-周围有许多技术提出了更强的耦合性，并有望缩短开发时间和提供更标准的路径。所以-在开始以未广泛使用的方式使用技术时，我必须谨慎。

据我了解，完全分离的SPA前端通常是由使用第三方API引起的。但是，当后端和前端都由一家公司开发时，这种去耦声音设计是否有效？

我目前选择的技术是Java / Spring后端和Angular2 / Web组件/聚合物前端-如果允许我这么说的话。但这与这个问题无关，因为这个问题是关于一般设计而不是具体技术的选择？

— 汤姆
source

（1）。是。现在这天很正常。

— 2016年

（2）。So - I must be cautious when starting to use technologies in manner which is not widely used.是的，如果您打算使用锤子敲打丝绸，则必须谨慎。也许这不是正确的工具。

— 2016年

请注意，以这种严格的方式进行解耦会产生大量的前期开发成本。您需要从中获得一些具体的价值。

— usr

另请注意，您永远无法直接将域公开给浏览器。这会造成安全问题，并且数据将无法正确格式化以进行显示。您将只需要创建一个特殊目的（REST）接口即可调用JavaScript。而且这是耦合的。

— usr

Spring具有批注PathVariable，ResponseBody，RequestBody和RestController（您应将其签出）。它们使开发基于Ajax的JSON / REST Web应用程序变得非常非常容易，这使Spring成为SPA的绝佳后端。我坚信以这种方式将前端和后端分开是更好的选择：我曾“高兴”使用的经典JSF应用程序很烂。

— Traubenfuchs

Answers:

完全分离后端和前端Web应用程序并允许它们与（JSON）REST API通信是正常的设计吗？

是的，这很正常。但这只是正常情况，除非您需要进行这种分离，并且不将这种设置强加到整个应用程序中。

SPA带有一些与之相关的问题。现在，我脑海中浮现出一些东西：

主要是JavaScript。由于该Javascript错误，您的应用程序部分中的一个错误可能会阻止应用程序的其他部分工作。使用服务器（SpringMVC，PHP等）提供的页面，您可以重新加载新的部分；
CORS。不一定是强制性的，但后端通常与前端使用不同的域名。因此，现在您必须处理浏览器安全问题；
SEO。你需要这个吗？您的网站是公开的吗？Google可以理解Javascript，并尝试在您的网站之外发挥作用，但您基本上是将控制权交给了机器人并希望获得最好的效果。收回控制权可能意味着必须依赖其他工具，例如PhantomJS。
独立的前端应用程序意味着独立的项目，部署管道，额外的工具等；
当所有代码都在客户端上时，安全性很难实现；

当然，还有SPA优势：

在前端与用户完全交互，仅根据需要从服务器加载数据。更好的响应速度和用户体验；
根据应用程序的不同，在客户端上执行的某些处理意味着您可以节省服务器的这些计算量。
在发展后端和前端时具有更好的灵活性（您可以单独进行）；
如果您的后端本质上是一个API，则可以在其前面放置其他客户端，例如本机Android / iPhone应用程序；
对于前端开发人员而言，这种分离可能使他们更容易进行CSS / HTML，而无需在其计算机上运行服务器应用程序。

因此，这两种方法（SPA与服务器页面）各有利弊。花一些时间研究这两个选项，然后根据您的情况进行选择。

— 博格丹
source

“当所有代码都在客户端上时，很难实现安全性；” 嗯，相反，这是一个很大的优点，安全性更容易实现，因为您必须保护一个非常清晰的层，该层是以逻辑和易于理解的方式设计的。

— David Mulder

@DavidMulder：有了透明层，安全性很难实现，但是更容易正确地实现。如果没有明确的区分，您可能会很快就说出似乎是合理的但错误的事情；-)

— 史蒂夫·杰索普

您问题的答案很简单。是。您建议的是一种合理的方法。但是，我想您想问的是，这是否是更好的方法，不幸的是，我们谁也无法为您回答。涉及的因素涉及太多方面，因此如果不透露有关组织和产品要求的所有内容，就无法得出真正的结论。我认为您已经知道该怎么做。

— 萨马兹
source

注意事项正常。

前端javascript框架的功能有限。如果创建供多个应用程序使用的原始api，则通常需要在服务器端对原始api调用进行一些服务器端处理，以处理与该特定应用程序一起工作的视图模型。

因此，“正常”架构可能是：

database
business logic services (dll)
api exposing business logic
server side website exposing viewmodels and functionality via json rest endpoints
client side javascript implementing ui

现在，如果只有一个Web应用程序，则可以切出“ API公开业务逻辑”层，而只需让服务器端Web代码直接调用业务逻辑即可。

因为您已经将业务逻辑分离到了自己的库中，所以它仍然与ui逻辑脱钩，您以后可以随时添加服务层。

同样，由于api服务是由服务器端代码调用的，因此您不受HTTP通信的限制。（尽管现在这已经很普遍了）

此外，让javascript调用与其提供服务的主机相同的主机，就意味着您不必操心cors

— 伊万
source