我们即将开发一个 Web 服务，它将具有一些“社交”功能。我们需要为移动设备（至少 iOS/Android）创建一个（响应式）网站和应用程序。
我已经开发了具有 API 的 Web 服务（用于应用程序访问；通常不公开）。但是，这一次我正在考虑采用一种不同的、还原的方法，我想对此提出一些意见。
我没有开发网站，然后在其上添加 API 以让应用程序与服务通信，而是考虑从 API 开始，然后在其上构建所有内容（包括网站）。然后，将有一个与数据库通信的服务（PHP 或 Node.js 应用程序），并且网站（在服务器端，而不是客户端）和应用程序都将与该服务器通信。
这种方法的积极优势：
但是，我也知道这种方法需要在网站和数据库之间创建一个额外的层，这可能会对性能产生负面影响。
你怎么看？您有这种设计或案例研究的经验吗？
这是一种非常合适的方法，并且被包括我在内的许多公司成功使用。
我们倾向于从允许访问 Javascript/HTML 网络应用程序的 API 套件开始。我们主要使用 AngularJS 来创建 Web 应用程序。
作为一个额外的层（您已经确定），我们有时还会创建更传统的服务器端应用程序作为 Web 服务的客户端。这通常感觉比仅仅创建具有不同（但相似）子系统（例如数据访问、身份验证）的单独应用程序要多得多的工作。但是，一旦您构建了这些层和“主要”应用程序，您就可以免费获得 Web 服务！您可以发布带有一些文档的 API 套件供集成合作伙伴使用，并且您可以在与 Web 应用程序相同的后端构建移动应用程序。
我们发现的主要好处是，随着项目的成熟，需要测试和维护的东西更少，同时保留了异构的连接客户。
祝你好运
我认为这是完全合理的。任何性能问题都可以通过使用良好的单页 Web 应用程序框架（如Ember、Angular等）和/或使用类似Bacon的一些函数式反应式编程来缓解。
基本上，尽可能使 Web 组件异步。当您了解这一点时，我认为代码重用和可伸缩性将非常有利于您。
对于一个严肃的应用程序，你应该总是有某种“服务”层和/或“消息总线”层，但这不等于“ API ”。恕我直言，API 是公开的，很少更改，任何新网站都不会如此。此外，您的网站可能会有与您的移动应用程序不同的要求。
但是您的想法的精神是正确的，您应该争取分离，只是要意识到您需要做到这一点，以便您可以快速做出改变。因此（我不能强调）这一点：你不需要面向服务架构的物理分离。您可以只分离您的代码并遵循SOA的黄金法则：状态和行为分离（即无状态，您有服务对象和数据对象，没有 OOP）。我经常看到需要进行更改的项目，因为一开始有太多的物理分离（即过度设计）。
您还应该知道何时要基于 RPC（REST、请求/响应和同步）与基于事件消息（MQ、发布/订阅和异步）。大多数 Web 应用程序更喜欢 RPC，但移动和 HTML5 应用程序允许异步消息（websockets 或本机）。
这种方法听起来很有吸引力，但根据我的经验，它在未来可能会受到限制。一旦你（希望）拥有一个使用 API 的良好应用程序社区，就很难改变它。另一方面，您希望保留快速迭代您的网站的能力，而不必担心破坏第 3 方应用程序。
我觉得从长远来看，你最好拥有一个手工制作的 API 来支持你的 3rd 方开发人员想要的东西，以及一个单独的手工制作的 UI 或 API，它可以准确地提供你网站用户想要的东西。这些是不同的用户群体，很可能有不同的要求。
例如，您的应用程序可能需要一个能够执行类似 SQL 的查询（想想 OData）并显示实体的大量详细信息的丰富 API。您的第 3 方可能更喜欢更简单的 API，它只允许使用您的实体属性的一小部分进行批量请求/更新 - 例如用于同步用例。
尝试创建一个同时支持您的应用程序和 3rd 方应用程序的 API 可能会让您无法满足其中任何一个。
注意：我不反对 API 的用户提供分离等。我说的是为您的应用程序和 3rd 方应用程序使用通用 API。