在创建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/

我决定对Infiniforms采用选项2的体系结构，因为它提供了一种将UI与业务逻辑分离的好方法。

这样做的一个优点是API服务器可以独立于web服务器进行扩展。如果你有多个客户端，那么网站就不需要像web服务器那样扩展，因为一些客户端是基于手机/平板电脑或桌面的。

这种方法还为您向用户开放API提供了良好的基础，特别是当您使用自己的API为您的网站提供所有功能时。

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

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

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

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 +许多客户端使用它的例子。

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

一个非常好的问题，我很惊讶，因为我认为这是一个非常普遍的任务，现在我会有足够的资源来解决这个问题，然而事实并非如此。

我的想法如下: -创建一些在API控制器和HTML控制器之间具有公共逻辑的模块，而不返回json或呈现HTML，并将此模块包含在HTML控制器和API控制器中，然后做任何你想做的事情，例如:

module WebAndAPICommon
    module Products

        def index
            @products = # do some logic here that will set @products variable
        end

    end
end


class ProductsController < ApplicationController
    # default products controlelr, for rendering HMTL pages 
    include WebAndAPICommon

    def index
        super
    end

end



module API
    class ProductsController
        include WebAndAPICommon

        def index
            super
            render json: @products
        end

    end
end