如何考虑Angular.js应用程序使用的REST-api的设计和目的

Question

我们有一个整体，如今既充当业务引擎，又提供Web UI。 我现在正在做的工作是将UI职责分离到一个新的组件，该组件将为浏览器提供Angular应用程序。 这个新组件将通过REST与业务引擎和其他组件进行通信。

所以我们有一个外部REST-api和一个内部REST-api。 外部REST接收来自UI客户端的请求，并通过向内部REST-api发出新请求来提供此请求。

引入外部REST-api的原因是客户端应该只有一个单一的联系点来与系统进行通信，从而减轻了安全问题。

我的问题是，我是否应该将外部REST-api设计为纯代理，只需将每个请求传递给内部REST-api上的结构上等效的请求。 或者，如果我应该允许外部REST-api按摩从内部REST-api返回的模型，那么它的响应更多，使用一个可以直接使用Angular应用程序的viewModel。 因此，选择在客户端，即Angular.js控制器或外部REST组件中按摩模型。 通常情况下，我会在服务器端进行按摩，以使客户端开发尽可能简化。 但这可能是因为我主要是一个后端开发人员，而更喜欢在那里编写代码。 随着Angular.js等的出现，首选方法可能是将这个问题传递给客户端？ 你有什么看法？

Answer 1

我们也有类似的问题，比如利用Google OAuth登录用户。

我们总是通过后端SpringMVC包装外部REST API。 也就是说，如果我们想从Google调用API /google/res ，我们会将其包装到内部API /internal/res 。 而前端（Angular）总是调用/internal/res 。

一个非常简单的原因是我们可以更轻松地控制用户权限。 此外，我们可以按照API添加更多信息。 例如，我们会将会话用户与Google帐户相关联。

在公共API方面，我认为从前端调用外部RESTful服务是可以的。 但在我看来，为了确保安全性，后端处理始终是首选。