我更倾向于选择第二条和第三条。主要是因为第一条违反了关注点的分离，并且混合了各种各样的东西。最终，你会发现需要有一个没有匹配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个或者它们的混合。

在Rails中构建JSONAPI是一流的，JSONAPI::Resources gem为http://jsonapi.org指定的API做了繁重的工作。

REST服务器+ javascript为主的客户端是我在最近的工作中遵循的原则。

REST服务器是在node.js + Express + MongoDB(非常好的写作性能)+ Mongoose ODM(非常适合建模数据，包括验证)+ CoffeeScript(我现在用ES2015代替)中实现的，这对我来说很好。与其他可能的服务器端技术相比，Node.js可能相对年轻，但它使我能够编写集成了支付的可靠API。

我使用Ember.js作为JavaScript框架，大部分应用程序逻辑是在浏览器中执行的。我使用SASS(特别是SCSS)进行CSS预处理。

Ember是由强大的社区支持的成熟框架。它是一个非常强大的框架，最近有很多工作都集中在性能上，比如全新的Glimmer渲染引擎(灵感来自React)。

Ember核心团队正在开发FastBoot，它可以让你在服务器端(node.js具体)执行你的JavaScript Ember逻辑，并发送预渲染的应用程序HTML(通常在浏览器中运行)给用户。这是伟大的搜索引擎优化和用户体验，因为他不会等待那么长时间的页面显示。

Ember CLI是一个很好的工具，可以帮助你组织你的代码，它在不断增长的代码库中做得很好。烬也有它自己的插件生态系统，你可以选择从各种烬插件。你可以很容易地抓取Bootstrap(在我的情况下)或Foundation，并将其添加到你的应用程序。

不是通过Express来提供所有的服务，我选择使用nginx来提供图像和javascript较多的客户端。使用nginx代理在我的情况下是有帮助的:

upstream app_appName.com {
  # replace 0.0.0.0 with your IP address and 1000 with your port of node HTTP server
  server 0.0.0.0:1000;
  keepalive 8;
}

server {
  listen 80 default_server;
  listen [::]:80 default_server ipv6only=on;

  client_max_body_size 32M;

  access_log  /var/log/nginx/appName.access.log;
  error_log  /var/log/nginx/appName.error.log;

  server_name appName.com appName;

  location / {
     # frontend assets path
     root /var/www/html;
     index index.html;

     # to handle Ember routing
     try_files $uri $uri/ /index.html?/$request_uri;
  }

  location /i/ {
    alias /var/i/img/;
  }

  location /api/v1/ {
    proxy_pass  http://app_appName.com;

    proxy_next_upstream error timeout invalid_header http_500 http_502
http_503 http_504;
    proxy_redirect off;
    proxy_buffering off;
    proxy_set_header        Host            $host;
    proxy_set_header        X-Real-IP       $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
  }
}

利:我喜欢API和客户端的分离。聪明的人说这是 该走的路。理论上很好。看起来很前卫，令人兴奋。

我可以说它在实践中也很好。分离REST API的另一个优点是，以后可以在其他应用程序中重用它。在理想的情况下，你不仅可以在网页上使用相同的REST API，如果你决定编写一个移动应用程序，也可以在移动应用程序上使用。

弊:没有太多先例。这方面做得好的例子不多。公共 例子(twitter.com)感觉迟钝，甚至切换 这种方法。

现在情况看起来不一样了。有很多使用REST API +许多客户端使用它的例子。

我喜欢#3，当我的网站不是100%的CRUD实现我的数据。这种情况尚未发生。

我更喜欢sinatra，只会把应用程序分成几个不同的机架应用程序与不同的目的。我会做一个API特定的机架应用程序，将涵盖我需要的API。然后可能是一个用户机架应用程序，将呈现我的网页。有时该版本会在需要时查询API，但通常它只关心html站点。

我不担心它，只要从用户端做一个持久化层查询，如果我需要它。我不太关心创建一个完全的分离，因为他们通常最终服务于不同的目的。

下面是一个使用多个机架应用程序的简单示例。我在那里添加了一个jquery的快速示例，让你看到它击中API应用程序。你可以看到sinatra和安装多个不同用途的机架应用程序是多么简单。

https://github.com/dusty/multi-rack-app-app

我个人更倾向于选择(3)作为解决方案。我的前雇主(家喻户晓的名字)几乎所有的网站都在使用它。这意味着你可以找一些了解Javascript、浏览器特性等的前端开发人员来编写你的前端代码。他们只需要知道“curl xyz，你会得到一些json”，然后他们就开始了。

同时，你的重量级后端人员可以编写Json提供程序。这些人根本不需要考虑表示，而是担心零散的后端、超时、优雅的错误处理、数据库连接池、线程和扩展等。

选项3为您提供了一个良好、可靠的三层架构。这意味着你从前端输出的东西是SEO友好的，可以用于旧的或新的浏览器(以及那些关闭了JS的浏览器)，如果你愿意，仍然可以是Javascript客户端模板(所以你可以用静态HTML处理旧的浏览器/googlebot，但将JS构建的动态体验发送给使用最新Chrome浏览器或其他浏览器的人)。

在我看到的所有情况下，选项3都是一些PHP的自定义实现，不能在项目之间特别转换，更不用说开源领域了。我猜最近PHP可能已经被Ruby/Rails取代了，但同样的事情仍然是正确的。

FWIW， $current_employer可以在几个重要的地方使用选项3。我正在寻找一个好的Ruby框架来构建一些东西。我确信我可以把一大堆宝石粘在一起，但我更喜欢一个广泛提供模板、“卷曲”、可选身份验证、可选memcache/nosql连接缓存解决方案的单一产品。这里我找不到任何有条理的东西:-(

这里已经有一些很好的答案了——我肯定会推荐第2条或第3条——分离在概念上很好，在实践中也很好。

很难预测API上的负载和流量模式等事情，而我们看到的那些独立为API提供服务的客户更容易进行配置和扩展。如果你必须在人类的网络访问模式中做到这一点，那就不那么容易了。此外，你的API使用可能会比你的web客户端增长得更快，然后你就可以看到你的努力方向了。

在#2 #3之间，这真的取决于你的目标-我同意#2可能是web应用程序的未来-但也许你想要一些更直接的东西，如果那个频道只是众多频道中的一个!