我更倾向于选择第二条和第三条。主要是因为第一条违反了关注点的分离，并且混合了各种各样的东西。最终，你会发现需要有一个没有匹配HTML页面的API端点/等等，你会在同一个代码库中遇到HTML和JSON端点混合的麻烦。它变得一团糟，即使它是MVP，你最终也不得不重写它，因为它太混乱了，甚至不值得挽救。

Going with #2 or #3 allows you to completely have a API that acts the same (for the most part) regardless. This provides great flexibility. I'm not 100% sold on Backbone/ember/whatever/etc.js just yet. I think its great, but as we're seeing with twitter this is not optimal. BUT... Twitter is also a huge beast of a company and has hundreds of millions of users. So any improvement can have a huge impact to bottom line on various areas of various business units. I think there is more to the decision than speed alone and they're not letting us in on that. But thats just my opinion. However, I do not discount backbone and its competitors. These apps are great to use and are very clean and are very responsive (for the most part).

第三种选择也有一定的吸引力。这就是我遵循帕累托原则(80/20规则)的地方，让20%的主标记(反之亦然)在服务器上呈现，然后让一个漂亮的JS客户端(backbone/etc)运行剩下的部分。你可能不会通过JS客户端与REST api进行100%的通信，但如果有必要的话，你会做一些工作来让suer体验更好。

我认为这是一个“视情况而定”的问题，答案是“这取决于”你在做什么，你在为谁服务，以及你希望他们得到什么样的体验。我认为你可以选择2个或3个或者它们的混合。

在创建gauge .es时，我们选择了#2。我负责API (ruby, sinatra等)，我的业务伙伴Steve Smith负责前端(javascript客户端)。

优点:

Move quickly in parallel. If I worked ahead of Steve, I could keep creating APIs for new features. If he worked ahead of me, he could fake out the API very easily and build the UI. API for free. Having open access to the data in your app is quickly becoming a standard feature. If you start with an API from the ground up, you get this for free. Clean separation. It is better to think of your app as an API with clients. Sure, the first and most important client may be a web one, but it sets you up for easily creating other clients (iPhone, Android).

缺点:

向后兼容性。这与API的关系比你直接的问题更大，但一旦你的API出来了，你就不能破坏它，也不能破坏所有的客户端。这并不意味着你要放慢速度，但它确实意味着你必须经常同时做两件事。添加到API或新字段是可以的，但是在没有版本控制的情况下不应该进行更改/删除。

我现在想不出什么骗局了。

结论:如果你计划发布一个API, API + JS客户端是正确的选择。

另外，我还建议在发布API之前完整地记录它。编写gage .es API的过程确实帮助了我们进行imp操作

http://get.gaug.es/documentation/api/

我更倾向于选择第二条和第三条。主要是因为第一条违反了关注点的分离，并且混合了各种各样的东西。最终，你会发现需要有一个没有匹配HTML页面的API端点/等等，你会在同一个代码库中遇到HTML和JSON端点混合的麻烦。它变得一团糟，即使它是MVP，你最终也不得不重写它，因为它太混乱了，甚至不值得挽救。

Going with #2 or #3 allows you to completely have a API that acts the same (for the most part) regardless. This provides great flexibility. I'm not 100% sold on Backbone/ember/whatever/etc.js just yet. I think its great, but as we're seeing with twitter this is not optimal. BUT... Twitter is also a huge beast of a company and has hundreds of millions of users. So any improvement can have a huge impact to bottom line on various areas of various business units. I think there is more to the decision than speed alone and they're not letting us in on that. But thats just my opinion. However, I do not discount backbone and its competitors. These apps are great to use and are very clean and are very responsive (for the most part).

第三种选择也有一定的吸引力。这就是我遵循帕累托原则(80/20规则)的地方，让20%的主标记(反之亦然)在服务器上呈现，然后让一个漂亮的JS客户端(backbone/etc)运行剩下的部分。你可能不会通过JS客户端与REST api进行100%的通信，但如果有必要的话，你会做一些工作来让suer体验更好。

我认为这是一个“视情况而定”的问题，答案是“这取决于”你在做什么，你在为谁服务，以及你希望他们得到什么样的体验。我认为你可以选择2个或3个或者它们的混合。

在Boundless，我们已经深入研究了第2个选项，并将其推广给了数千名学生。我们的服务器是一个JSON REST API (Scala + MongoDB)，我们所有的客户端代码都是直接从CloudFront提供的(即:www.boundless.com只是CloudFront的别名)。

优点:

尖端的/令人兴奋 好处多多:API为你自己的web客户端、移动客户端、第三方访问等提供了基础。 非常快的网站加载/页面转换

缺点:

不SEO友好/准备没有更多的工作。 需要一流的web前端人员，他们准备好应对网站体验的现实，70%是javascript和这意味着什么。

我认为这是所有网络应用程序的未来。

对web前端人员的一些想法(这是这个架构所具有的所有新事物/挑战):

CoffeeScript。更容易生成高质量的代码。 骨干。组织逻辑和活跃社区的好方法。 HAMLC。Haml + CoffeeScript模板=> JS。 萨斯

我们已经为我们的前端开发构建了一个名为“Spar”(单页应用Rocketship)的工具，它实际上是Rails为单页应用开发调整的资产管道。我们将在接下来的几周内在我们的github页面上开放源代码，同时还有一篇博客文章解释如何使用它和更详细的整体架构。

更新:

With respect to people's concerns with Backbone, I think they are over-rated. Backbone is far more an organizational principle than it is a deep framework. Twitter's site itself is a giant beast of Javascript covering every corner-case across millions of users & legacy browsers, while loading tweets real-time, garbage collect, display lots of multimedia, etc. Of all the 'pure' js sites I've seen, Twitter is the odd one out. There have been many impressively complicated apps delivered via JS that fare very well.

体系结构的选择完全取决于您的目标。如果您正在寻找支持多个客户端的最快方式，并有机会接触到优秀的前端人才，那么投资一个独立的API是一个很好的方法。

我的3个月项目已经进行了2个月，采用了你在这里概述的第二种方法。我们使用一个RESTful API服务器端，前端是backbone.js。js管理模板，jQuery处理AJAX和DOM操作。对于旧的浏览器和搜索蜘蛛，我们已经退回到服务器端渲染，但是我们使用的是与使用Mozilla Rhino的Handlebars前端相同的HTML模板。

我们选择这种方法有很多不同的原因，但我们非常清楚，因为它还没有在大范围内得到证明，所以它有点冒险。尽管如此，到目前为止一切都进行得很顺利。。

到目前为止，我们一直在使用一个API，但在项目的下一个阶段，我们将使用第二个API。第一个用于大量数据，第二个更像一个通过API的CMS。

让项目的这两个部分彼此完全独立是选择这个基础设施的关键考虑因素。如果您正在寻找一种架构，可以在没有任何依赖的情况下混搭不同的独立资源，那么这种方法值得一试。

恐怕我不是Ruby的人，所以我不能评论其他方法。有时候冒险一下是可以的。其他时候最好谨慎行事。你会根据项目的类型来了解自己。

祝你选对了。也热衷于看别人分享什么。

我们使用#3的以下变体: 制作一个JSON-only REST API服务器。制作一个HTML网站服务器。HTML web服务器不是REST API服务器的客户端。相反，这两家公司是同行。在表面下不远的地方，有一个内部API提供两个服务器所需的功能。

我们不知道有任何先例，所以这是一种实验。到目前为止(即将进入测试阶段)，它的效果相当不错。