单独的REST后端API的优点？

Question

背景：我是一名初学程序员，自学成才，希望能成为一名SPA。我开始使用JavaScript，Jquery，PHP和MySQL，现在对所有人都非常有信心。我已经开始使用Ember了，现在我正在从使用PHP API转向Node。这让我更接近Meteor ......我知道我需要使用Mongo，但是前后集成似乎是明智的并且有一些优势。

所以我的问题是拥有单独的REST后端API（例如Express）而不是集成的前端/后端（例如Meteor）有什么好处。

让我想到的是，我的应用程序将基于平板电脑/ PC，但将来我会想要一个不同的移动版本，所以我只能使用相同的API。我意识到上述问题是这个堆栈问题的主要问题，但也许如果一个流星开发者可以澄清这是否确实是一个问题。

提前致谢！

Answer 1

对我而言，使用rest API可以获得很多优势，它们是轻量级的，可扩展的，并且可以重复使用。

今天使用垂直架构的趋势意味着拥有一个单一责任的RestFul服务，为什么因为它更好地扩展并且更容易将团队分配给api，这样你就能够管理几个团队和apis以非常有序的方式。这可能是Twitter，wunderlist和其他公司的工作方式，因为它是一种更好的扩展解决方案。

由Raffi Krikorian看看这个talk他是推特的架构负责人，有一段时间有点旧，但它值得每一分钟并说明一些优点。 你也可以看看下面的图表，我刚才解释了MVC和API第一类架构之间的差异。

我使用角度和休息服务创作了一个休息应用程序，对我来说这是一个非常好的经历，无法回头。

祝你好运

Answer 2

Meteor并没有真正整合＆＃34;您描述的前端（客户端）和后端（服务器）。它仍将它们保持为两个独立的层。流星之美（除了疯狂的反应之外）是它在任何地方使用Javascript，而不是在客户端上使用JS和服务器上的其他语言，因此您可以在前端和后端使用相同的API。尽管Meteor确实让你在同一个文件中编写客户端和服务器代码，但它仍然要求你区分这两者，服务器代码仍然只存储在服务器上，而客户端代码仍然是服务于客户端的

流星仍然很年轻，但是开发人员和社区非常活跃，此时您所描述的一切都可以通过它实现。我现在已经和Meteor合作了大约6个月了，它还没让我失望。我正在开发一个生产级应用程序，该应用程序还需要在移动应用程序中公开REST API，我在Meteor上做得非常成功（我刚刚使用Android端口的REST端点更新了用户配置文件）设备，并实时观看它在Meteor应用程序中的变化。太酷了！）。

我正在使用这个很棒的软件包RestStop2来在meteor中构建REST API，但遗憾的是它被弃用了，所以我发布了一个更新版本。请查看Meteor中构建REST API的示例。它可以通过Meteor包管理器获得：https://atmospherejs.com/nimble/restivus

因此，为了回答您的问题，您总是希望将REST API分离到它自己的层中，但这完全可以通过Meteor实现。为清楚起见，您永远不会在Meteor应用程序中使用此REST API。 Meteor使用DDP（而不是HTTP），这使您可以更直接地与服务器建立连接，因此如果您通过HTTP从Meteor客户端访问Meteor服务器上的数据，那么您就会出错。当然，使用Meteor，您可以使用REST API中的现有代码。

这是一篇非常好的文章，解释了在Meteor中编写REST API的一些注意事项：http://www.meteorpedia.com/read/REST_API。

Answer 3

在前端，后端（Rest Api）和DB等层中分离的体系结构的设计，是为了获得更好的应用程序功能的可伸缩性，可重用性和逻辑分隔符。例如：

  

今天将Web应用程序分成3层（前端，后端，   和数据库），如果明天你想做一个移动应用程序，你可以   像前端层中的额外项目一样开发应用程序，   但使用后端开发的所有功能。然后是前端   应用程序不需要服务器为什么在每个设备内运行，但也许   后端服务器中的负载增加，您只需要再添加1个   后端层的服务器。

这是一个小例子，但却是移动应用新时代最常见的例子。

在MVC架构中始终记住这一点：

前端：始终从后端调用服务，渲染视图和捕获数据。有时候做一个小小的逻辑。

后端：接收请求，应用所有业务逻辑，读取和写入数据库中的操作，并返回以json格式首选的响应。

模型：存储数据，备份，从属等。

PD：如果你在这个例子中使用meteor，你需要制作一个api Rest来开发移动应用程序。