前部-后端对决。后端-后端

Question

我见过这种模式出现在几个不同的团队中。他们有一个带有REST和前端web项目的服务器。

通常发生的情况是，前端开发人员发现他们的请求被CORS阻塞了，他们为前端创建了REST，该API只将请求传递到主后端。这个API最终捕获了一些业务逻辑，并将其转换为自己的服务器，处理与真正后端服务器分开的一半后端责任。

怎样才能防止这种模式？在两个API项目之间传播业务逻辑和必须运行两个API才能使用前端是错误的。是否有一种正确的方法，使一个“设置和遗忘”的CORS代理前端，而不创造一个倾销场？

Answer 1

我能看到的唯一场景是，当主API没有以公共子域发布时，您可能会屏蔽它，将中间公共“后端”发布到专用网络中的API代理请求，或者您有一个前端后端(假设AngularJS中具有不同的临时前端，React或任何其他客户端技术)，它们使用来自其他API的服务，所以您有来自其他API的CMS功能和数据，我已经看到了这两种情况。

CORS的问题大多来自对这一机制的误解。https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

如果API是公开的，那么您只需要为调用子域(请求的起源)配置访问控制-允许-原产地:这样，您只需担心在发送头部时不会更改任何内容。

当然，CORS的目的是在不同的服务器之间安全地共享数据，托管不同的应用程序，因为API可能拒绝来自访问控制-允许-原产地指定的子域的任何请求：

否则，具有不同或互补的业务逻辑的两个后端可能会导致灾难，因为对前端所做的任何更改都很容易导致更改两个后端中的代码，从而使维护变得更加困难。