Web服务和API：“鸡肉或鸡蛋”

Question

我们即将开发一种具有一些“社交”功能的网络服务。 我们需要创建一个（响应式）网站和移动应用程序（至少iOS / Android）。

我已经开发了具有API的Web服务（用于app访问;通常不公开）。但是，这次我正在考虑应用一种不同的，还原的方法，我想对此有一些看法。

我没有开发网站然后在其上添加API以让应用程序与服务进行通信，而是考虑从API开始，然后在其上构建所有内容（包括网站）。那么，将是一个与数据库通信的服务（PHP或Node.js应用程序），并且网站（在服务器端，而不是客户端）和应用程序将与该服务器通信。 / p>

这种方法的积极优势：

1. 数据和视图之间的完全分离。该网站将在与API后端不同的独立服务器上运行。
2. 可能更具可扩展性

但是，我也知道这种方法需要在网站和数据库之间创建一个额外的层，这可能会对性能产生负面影响。

你怎么看？您是否有使用此设计或案例研究的经验？

Answer 1

这是一种非常合适的方法，也是包括我在内的许多公司成功使用的方法。

我们倾向于从API套件开始，该套件允许访问Javascript / HTML Web应用程序。我们主要使用AngularJS来创建Web应用程序。

作为一个额外的层（您已经确定），我们有时也会创建更传统的服务器端应用程序作为Web服务的客户端。这通常比仅创建具有不同（但相似）子系统的单独应用程序（例如数据访问，身份验证）要多得多。但是，一旦构建了这些图层和“主要”应用程序，您就可以免费获得Web服务！您可以发布API套件，其中包含一些供集成合作伙伴使用的文档，您可以在与Web应用程序相同的后端构建移动应用程序。

我们发现的主要好处是，随着项目的成熟，测试和维护的次数减少，同时保留了异构的连接客户端。

祝你好运

Answer 2

我认为这是完全合理的。通过使用良好的单页面Web应用程序框架（如Ember，Angular等）和/或某些功能性反应式编程（例如Bacon），可以消除任何性能问题。

基本上，尽可能使Web组件变为异步。当你完成这些工作时，我认为代码重用和可扩展性将对你有利。

Answer 3

对于严肃的应用程序，您应始终拥有某种“service”层和/或“消息总线”层，但不等于“ API ”。根据定义，恕我直言，API是公开的，很少有变化，对于任何新网站都不会如此。此外，您的网站可能会与您的移动应用程序有不同的要求。

但是你的想法的精神是正确的，你应该努力分离，只要意识到你需要做到这一点，以便你可以迅速做出改变。因此（我不能强调）这一点：您不需要面向服务架构的物理分离。你可以分开你的代码并遵循SOA的黄金法则：分离状态和行为（即无状态，你有服务对象和数据对象，没有OOP）。我经常看到需要做出改变的项目需要这么多，因为一开始就有太多的物理分离（即过度工程）。

此外，您应该知道何时需要基于RPC （REST，请求/响应和同步）与基于事件消息（MQ，pub / sub和异步） 。大多数Web应用程序更喜欢RPC，但移动和HTML5应用程序允许异步消息（websockets或native）。

Answer 4

这种方法听起来很有吸引力，但根据我的经验，它可能在未来受到限制。一旦你（希望）有一个使用你的API的良好应用程序社区，就很难改变它。另一方面，您希望保留快速迭代网站的能力，而不必担心破坏第三方应用程序。

我觉得从长远来看，你最好拥有一个手工制作的API来支持你的第三方开发者想要的东西，以及一个单独的手工制作的UI或API，它可以提供网站用户所需的内容。这些是用户的不同选区，可能会有不同的要求。

例如，您的应用程序可能需要一个富API，能够执行类似SQL的查询（想想OData）并显示实体的大量细节。您的第三方可能更喜欢更简单的API，它只允许批量请求/更新与您实体的一小部分属性 - 例如同步用例。

尝试创建支持您的应用和第三方应用的API可能会让您无法满足。

注意：我不反对API的用户提供分离等。我正在谈论为您的应用和第三方应用使用通用API。