问得好。+ 1。当然，这对我将来是一个有用的参考。此外，@Aaron和其他人也为讨论提供了价值。 和Ruby一样，这个问题同样适用于其他编程环境。

我使用了前两个选项。第一个用于许多应用程序，第二个用于我的开源项目Cowoop

选项1 这无疑是最受欢迎的一个。但我发现实现是非常http的。每个API的初始代码都用于处理请求对象。所以API代码不仅仅是纯粹的ruby/python/其他语言代码。

Option 2 I always loved this. This option also implies that HTML is not runtime generated on server. This is how option 2 is different from option 3. But are build as static html using a build script. When loaded on client side these HTML would call API server as JS API client. Separation of concerns is great advantage. And very much to your liking (and mine) backend experts implement backend APIs, test them easily like usual language code without worrying about framework/ http request code. This really is not as difficult as it sounds on frontend side. Do API calls and resulting data (mostly json) is available to your client side template or MVC. Less server side processing. It means you may go for commodity hardware/ less expensive server. Easier to test layers independently, easier to generate API docs. It does have some downsides. Many developers find this over engineered and hard to understand. So chances are that architecture may get criticized. i18n/l10n is hard. Since HTML is essentially generated build time are static, one needs multiple builds per supported language (which isn't necessarily a bad thing). But even with that you may have corner cases around l10n/i18n and need to be careful.

Option 3 Backend coding in this case must be same as second option. Most points for option 2 are applicable here as well. Web pages are rendered runtime using server side templates. This makes i18n/l10n much easier with more established/accepted techniques. May be one less http call for some essential context needed for page rendering like user, language, currency etc. So server side processing is increased with rendering but possibly compensated by less http calls to API server. Now that pages are server rendered on server, frontend is now more tied with programming environment. This might not be even a consideration for many applications.

Twitter的情况下

据我所知，Twitter可能会在服务器上进行初始页面渲染，但对于页面更新，它仍然有一些API调用和客户端模板来操作DOM。所以在这种情况下，你需要维护两个模板，这增加了一些开销和复杂性。不是每个人都能负担得起这个选项，不像Twitter。

我们的项目Stack

我碰巧使用Python。我使用JsonRPC 2.0代替REST。我建议使用REST，尽管出于各种原因我喜欢JsonRPC的想法。我使用下面的库。考虑选项2/3的人可能会觉得有用。

一个快速的web微框架- Flask 前端服务器:Nginx 客户端MVC: Knockout.js 其他相关工具/库: Jquery js代表货币 Webshim:跨浏览器填充 director:客户端路由 生成HTML

我的结论和建议

选项3 !

总之，我已经成功地使用了选项2，但现在为了简单起见，我倾向于选项3。使用构建脚本生成静态HTML页面，并使用专门提供静态页面的超高速服务器提供这些页面是非常诱人的(选项2)。

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

我的想法如下: -创建一些在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

我通常会选择第二种方法，使用Rails来构建API，并为JS的东西提供主干。你甚至可以使用ActiveAdmin免费获得一个管理面板。 我已经发布了几十个带有这种后端的手机应用程序。 但这在很大程度上取决于你的应用是否具有交互性。

我在上次RubyDay上做了一个关于这种方法的演讲。: http://www.slideshare.net/matteocollina/enter-the-app-era-with-ruby-on-rails-rubyday

对于第三个选项，为了获得第二个的响应性，你可能想尝试pajax Github做的。

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

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

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

我目前正致力于将一个巨大的CMS从选项1转换为选项3，并且进展顺利。我们选择在服务器端呈现标记，因为SEO对我们来说很重要，我们希望网站在移动电话上表现良好。

我使用node.js作为客户端的后端和一些模块来帮助我。我在这个过程中有点早期，但基础已经设置好了，这是一个检查数据确保它全部呈现正确的问题。这是我正在使用的:

Express for the app's foundation. (https://github.com/visionmedia/express) Request to fetch the data. (https://github.com/mikeal/request) Underscore templates that get rendered server side. I reuse these on the client. (https://github.com/documentcloud/underscore) UTML wraps underscore's templates to make them work with Express. (https://github.com/mikefrey/utml) Upfront collects templates and let's you chose which get sent to the client. (https://github.com/mrDarcyMurphy/upfront) Express Expose passes the fetched data, some modules, and templates to the front-end. (https://github.com/visionmedia/express-expose) Backbone creates models and views on the front-end after swallowing the data that got passed along. (https://github.com/documentcloud/backbone)

这是堆栈的核心。我发现其他一些有用的模块:

法立科(https / / github.com/trek/fleck) 时刻(https / / github.com/timrwood/moment) 手写笔(https / / github.com/LearnBoost/stylus) 整合(https / / github.com/fat/smoosh) 虽然我正在寻找grunt (https//github.com/cowboy/grunt) 控制台跟踪(//github.com/LearnBoost/console-trace)。

不，我没有使用coffeescript。

这个选择对我来说非常有效。后端模型是不存在的，因为我们从API获得的数据结构良好，并且我将其逐字传递给前端。唯一的例外是我们的布局模型，我添加了一个属性，使渲染更智能和更轻。我没有使用任何花哨的模型库，只是一个函数，在初始化时添加我需要的东西并返回自己。

(抱歉奇怪的链接，我太n00b堆栈溢出让我张贴那么多)

我采用了一种混合的方法，我们使用Sinatra作为基础，ActiveRecord / Postgress等来提供页面路由(细长模板)，公开web应用程序可以使用的REST API。在早期的开发中，像填充选择选项这样的事情是通过helper渲染到精简模板中完成的，但当我们接近生产时，这就变成了对REST API的AJAX调用，因为我们开始更关心页面加载速度等等。

在Slim中很容易渲染出来的东西以这种方式处理，而东西(填充表单，从jQuery接收表单POST数据。验证的submitHandler等显然都是AJAX)

测试是一个问题。现在我正试图将JSON数据传递给Rack::Test POST测试。