AngularJS：服务器端架构答案

【问题标题】：AngularJS: Server Side ArchitectureAngularJS：服务器端架构
【发布时间】：2017-03-26 10:02:35
【问题描述】：

在我们的企业内部网中，我们有一些端点服务平台，如 BPM、文档管理系统等。这些端点服务公开了 REST API。我们使用 AngularJS 作为前端开发 Web 应用程序。

关于如何从 AngualJS 调用这些端点服务，有两种选择。

选项 1：鉴于这些端点服务公开 REST，直接从 AngualrJS 调用这些 REST API。

选项 2： 引入中间层（在 WebLogic 或 Tomcat 等应用服务器上）。构建调用端点 REST API 的 Java 应用层；并将其托管在这个 millde 层上。 AngularJS 调用这个中间层提供的 REST；这个中间层反过来调用端点 REST。

我个人更喜欢选项 1；但是 我邀请您就此事发表意见。我已经列出了选项 1 的优缺点。

选项 1 的优点：

选项 1 的缺点：

【问题讨论】：

【解决方案1】：

感谢这么好的文章。

如果您关注安全性并且您的项目要求侧重于安全性。必须选择选项 2。

如果安全不是一个大问题。选项 2 更好。

【讨论】：

【解决方案2】：

从长远来看，我认为选项 2 是一个更好的选择。有几个原因。

安全性是最重要的，如果你有一个中间件，你就可以拥有内在的安全性，这意味着你只能公开你的 Angular Web 应用程序需要的那些 REST API。您还可以包含像 oAuth 这样的安全机制，因为您可以控制中间件。

记录是另一种。当然，现在任何应用程序都需要某种审计。安全性和日志记录都是实际 REST 调用之前的层。

您可以在任何关键的 REST API 上添加一些方面，这样，如果调用该 API 来触发邮件，即使我们目前不需要这些灵活性，也总是很方便。

您可以有效地包括响应转换和错误处理。一旦你从服务获得响应，在你的中间件中你可以转换响应，删除不必要或关键的字段，变出一些值等。这一切都可以用 angular 来完成，但是真正的响应或错误会暴露给客户端。

您正确提到的缺点是性能是一个，但 imo 使您的 REST 中间件与服务 REST 保持同步更加糟糕。服务添加的任何新 API 都需要包含在中间件中，重新编译和重新部署。但这也取决于这些变化的可能性和频率是多少？对于任何这些更改，您无论如何都可能需要更改 angular webapp 以包含它。

【讨论】：

【解决方案3】：

您提到“在我们的公司内部网中”。根据端点的保护方式，选项 1 可能具有挑战性。

Angular 将在 Web 浏览器中运行，因此如果这些服务只能通过 VPN / Intranet 访问，则 Web 应用程序只有在您的计算机连接到该 Intranet 时才能工作（即，如果您运行它，它将无法工作）家）。

选项 1 的另一个安全挑战是，如果端点需要特殊的身份验证“秘密”（API 令牌、密码、证书等），那么这些秘密将暴露给使用网络应用程序的任何人，因为任何人都可以看到他们的浏览器和服务器之间的流量。使用选项 2，这些秘密可以隐藏在中间层之后。

最后，即使 Angular 直接与这些端点对话，您仍然需要将 HTML / JS / CSS 托管在某些网络服务器上。您可能不需要完整的应用程序服务器，但您需要一些东西来将您的网络浏览器指向。

如果这些问题不适用于您的案例，那么您和您的团队最满意的选项完全取决于您。

【讨论】：

感谢您的回复。这一切都说得通。但是，我所说的应用程序只有在用户连接到 Intranet 时才能访问。我对选项 2 的主要担忧是，我们必须创建自己的 REST 层，该层本质上只是简单地“包裹”在端点 REST 周围。
我不太了解您提到的安全挑战。我们的端点服务确实具有我们需要维护的令牌，例如JSESSIONID、LtpaToken（用于 WebSphere）。 LtpaToken 确实携带身份验证数据，但是即使使用选项 2，我们也需要将其传递给浏览器（以 cookie 的形式），以便浏览器将其返回给服务。对不起，我不能给你的答案投票，因为我没有这个权利（还）。但我喜欢你的回答。
我想这两种方法的原型可能是值得的，以“感觉”最适合您的方法。
确实如此；但是我会保持这个问题的开放性以获得其他人的观点。