在我看来，从长远来看，选项 2 是更好的选择.这样做的原因很少.

option 2 in my opinion is a better option in long run. There are few reasons for that.

安全是首要的，如果中间有一个中间件，你就可以拥有固有的安全性，这意味着你可以只公开你的 angular webapp 需要的那些 REST API.您还可以包含 oAuth 等安全机制，因为您可以控制中间件.

Security is first and foremost, If you have a middleware in between, you can have inherent security, which means you can expose only those REST APIs which your angular webapp needs. You can also include a security mechanism like oAuth since you control the middleware.

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

Logging is another one. for sure any application nowadays do need some sort of auditing. both security and logging are layers before your actual REST calls.

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

You would be able to add some aspects on any key REST API, such that in case if that API is called trigger a mail, it's always handy to have those flexibility even we don't need at the moment.

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

You can include response transformation and error handling efficiently. Once you get the response from service, in your middleware you can transform the response, remove unnecessary or critical fields, conjure some values etc. This all can be done with angular also but then the real response or error is exposed to the client.

不利的一面是，您正确地提到了性能是其中之一，但是让您的 REST 中间件与服务 REST 保持同步的 imo 更加有害.服务添加的任何新 API 都需要包含在中间件中，重新编译和重新部署.但这也取决于这些变化的可能性和频率是多少?对于任何这些更改，您无论如何可能需要在 angular webapp 中更改以包含它.

On the downside you rightly mentioned performance is one but imo keeping your REST middlware in sync with services REST is more bane. any new API added by services, needs to be included in middleware, recompiled and redeployed. But it also depends what are the likelihood and frequency of those changes? for any those changes you anyhow might need to change in angular webapp to include it.