我将要从头开始创建一堆Web应用程序。（有关概述，请参见http://50pop.com/code。）我希望它们能够从许多不同的客户端进行访问：前端网站，智能手机应用程序，后端Web服务等。因此，我真的想要一个每个JSON REST API。

另外，我更喜欢在后端上工作，所以我做白日梦，我只专注于API，并雇用其他人制作前端UI，无论是网站，iPhone，Android还是其他应用程序。

请帮助我决定我应该采用哪种方法：

齐心协力

制作一个非常标准的Rails网络应用程序。在控制器中，执行response_with开关，以提供JSON或HTML。JSON响应就是我的API。

优点：很多先例。高标准和以这种方式做事的许多例子。

缺点：不一定希望API与Web应用程序相同。不喜欢if / then response_with切换方法。混合两种截然不同的东西（UI + API）。

REST SERVER + JAVASCRIPT-HEAVY CLIENT

制作仅JSON的REST API服务器。将Backbone或Ember.js用于客户端JavaScript可直接访问API，并在浏览器中显示模板。

优点：我喜欢API和客户端的分离。聪明的人说这是要走的路。理论上很棒。似乎最前沿和令人兴奋。

缺点：没有多少先例。这样做的例子并不多。公开示例（twitter.com）感觉呆滞，甚至正在放弃这种方法。

REST SERVER +服务器端HTML客户端

制作仅JSON的REST API服务器。制作一个基本的HTML网站客户端，该客户端仅访问REST API。更少的客户端JavaScript。

优点：我喜欢API和客户端的分离。但是提供纯HTML5十分简单，而且不会占用大量客户端。

缺点：没有多少先例。这样做的例子并不多。框架也不支持这一点。不确定如何处理。

特别是从经验中寻求建议，而不仅仅是从理论上。

在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”（单页应用火箭），该线束实际上是Rails为单页应用开发而调整的资产管道。在接下来的几周内，我们将在github页面上开放源代码，并在博客文章中详细解释如何使用它和整个体系结构。

更新：

关于人们对骨干网的担忧，我认为他们被高估了。骨干远不是一个深层的框架，而是一种组织原则。Twitter的网站本身就是一堆巨大的Javascript脚本，涵盖了数百万个用户和旧版浏览器的每个角落，同时实时加载推文，垃圾回收，显示大量多媒体等。在我拥有的所有“纯” js网站中，看到，Twitter是奇怪的一出。通过JS提供了许多令人印象深刻的复杂应用程序，它们运行得非常好。

您对体系结构的选择完全取决于您的目标。如果您正在寻找支持多个客户并获得优秀前端人才的最快方法，那么投资独立的API是一个不错的选择。

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

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

选项1

无疑，这是最受欢迎的一款。但是我发现实现非常像http-ish。每个API的初始代码都用于处理请求对象。因此，API代码不仅仅是纯ruby / python /其他语言代码。

选项2

我一直很喜欢这个。

此选项还暗示HTML不是在服务器上运行时生成的。这就是选项2与选项3的不同之处。但是使用构建脚本将其构建为静态html。当在客户端加载时，这些HTML将调用API服务器作为JS API客户端。

• 关注点分离是很大的优势。而且，非常喜欢（和我的）后端专家实现后端API，可以像通常的语言代码一样轻松地对其进行测试，而无需担心框架/ http请求代码。

• 确实，这并不像在前端听起来那么困难。您的客户端模板或MVC可以使用API​​调用和生成的数据（主要是json）。

• 减少服务器端处理。这意味着您可能会购买商品硬件/较便宜的服务器。

• 更容易独立测试图层，更容易生成API文档。

它确实有一些缺点。

• 许多开发人员发现这过于工程化，难以理解。因此，架构可能会受到批评。

• i18n / l10n很难。由于HTML本质上是生成的，因此构建时间是静态的，因此每种受支持的语言都需要进行多个构建（这不一定是一件坏事）。但是即使这样，您可能还会遇到l10n / i18n左右的情况，因此需要小心。

选项3

在这种情况下，后端编码必须与第二个选项相同。选项2的大多数要点也适用于此。

使用服务器端模板在运行时呈现网页。通过更成熟/更被接受的技术，这使得i18n / l10n更加容易。对于页面呈现所需的一些基本上下文（例如用户，语言，货币等），可能减少了一个http调用。因此，随着呈现的增加，服务器端处理会增加，但可能会减少对API服务器的http调用。

现在页面已在服务器上呈现在服务器上，前端现在与编程环境更加紧密地联系在一起。对于许多应用程序，这甚至可能不是考虑因素。

Twitter案例

据我了解，Twitter可能会在服务器上进行其初始页面渲染，但是对于页面更新，它仍然具有一些API调用和用于处理DOM的客户端模板。因此，在这种情况下，您需要维护双重模板，这会增加一些开销和复杂性。与Twitter不同，并不是每个人都能负担得起此选项。

我们的项目堆栈

我碰巧使用Python。我使用JsonRPC 2.0而不是REST。我建议使用REST，尽管出于各种原因我喜欢JsonRPC的想法。我使用下面的库。有人考虑选择2/3可能会发现它很有用。

• API服务器：Python一个快速的Web微型框架-Flask
• 前端服务器：Nginx
• 客户端MVC：Knockout.js
• 其他相关工具/库：
  • jQuery的
  • 记帐货币的Accounting.js
  • Webshim：跨浏览器polyfill
  • 导演：客户端路由
  • sphc：HTML生成

我的结论和建议

选项3！

所有人都说过，我已经成功使用了选项2，但是为了简化起见，现在倾向于选项3。用构建脚本生成静态HTML页面，并使用专门提供静态页面的超快速服务器之一为它们提供服务是很诱人的（选项2）。

在构建gaug.es时，我们选择了＃2。我从事API（红宝石，sinatra等）的工作，而我的业务伙伴史蒂夫·史密斯则从事前端（javascript客户端）的工作。

优点：

1. 并行快速移动。如果我在Steve之前工作过，那么我可以继续为新功能创建API。如果他在我之前工作，那么他可以很容易地伪造API并构建UI。

2. API是免费的。可以对应用程序中的数据进行开放访问正迅速成为一项标准功能。如果您从头开始使用API​​，则可以免费获得。

3. 清洁分离。最好将您的应用程序视为具有客户端的API。当然，第一个也是最重要的客户端可能是一个Web客户端，但这使您可以轻松创建其他客户端（iPhone，Android）。

缺点：

1. 向后兼容。与您的直接问题相比，这与API更为相关，但是一旦您的API出现了，您就不能仅仅破坏它，或者就破坏所有客户两个。这并不意味着您必须放慢速度，而是意味着您必须经常使两项同时工作。可以在API或新字段中添加内容，但是如果没有版本控制，则不应进行更改/删除。

我现在想不出缺点了。

结论：如果计划发布API，则可以使用API​​ + JS客户端。

PS我也建议您在发布API之前先对其进行全面记录。记录Gaug.es API的过程确实帮助我们实现了

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

我更喜欢走＃2和＃3的路线。主要是因为＃1违反了关注点分离并且将各种东西混合在一起。最终，您将发现需要一个没有匹配的HTML页面/等的API端点，并且在同一代码库中混合了HTML和JSON端点的情况将使您陷入困境。即使它的MVP，它也变成了令人毛骨悚然的混乱，最终您将不得不重新编写它，因为它太乱了，甚至不值得挽救。

与＃2或＃3搭配使用可让您完全拥有一个在大多数情况下都发挥相同作用的API。这提供了极大的灵活性。我还没有100％在Backbone / ember / whatever / etc.js上出售。我认为它很棒，但是正如我们在Twitter上看到的那样，这并不是最佳选择。但是... Twitter还是公司的巨大野兽，拥有数亿用户。因此，任何改进都会对各个业务部门各个领域的底线产生巨大影响。我认为，决定的意义不仅仅在于速度，他们也没有让我们参与其中。但那只是我的个人意见。但是，我不打折骨干及其竞争对手。这些应用程序非常好用，非常干净，响应速度非常快（大部分情况下）。

第三种选择也具有一定的吸引力。这是我遵循Pareto原则（80/20规则）并在服务器上渲染20％的主标记（反之亦然），然后由一个不错的JS客户端（主干/等）运行其余代码的地方。您可能没有通过JS客户端与REST api进行100％的通信，但是如果有必要，您将做一些工作来改善用户体验。

我认为这是“取决于”种类的问题之一，而答案是“取决于”您在做什么，为谁服务以及希望他们获得什么样的经验。鉴于我认为您可以选择2或3，也可以混合使用。

我目前正在努力将大型CMS从选项1转换为选项3，并且进展顺利。我们选择在服务器端渲染标记，因为SEO对我们来说意义重大，并且我们希望这些网站在手机上表现良好。

我正在使用node.js作为客户端的后端，并使用了一些模块来帮助我。我还处于开发过程的早期阶段，但已经确定了基础，并且要仔细检查数据以确保所有内容正确显示。这是我正在使用的：

• 表示应用程式的基础。
  （https://github.com/visionmedia/express）
• 请求获取数据。
  （https://github.com/mikeal/request）
• 下划线模板，用于呈现服务器端。我在客户端上重复使用这些。
  （https://github.com/documentcloud/underscore）
• UTML包装下划线的模板以使其与Express一起使用。
  （https://github.com/mikefrey/utml）
• Upfront收集模板，让您选择将其发送到客户端的模板。
  （https://github.com/mrDarcyMurphy/upfront）
• Express Expose将获取的数据，某些模块和模板传递到前端。
  （https://github.com/visionmedia/express-expose）
• 吞噬传递的数据后，Backbone在前端创建模型和视图。
  （https://github.com/documentcloud/backbone）

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

• 斑点（https // github.com / trek / fleck）
• 瞬间（https // github.com / timrwood / moment）
• 触控笔（https // github.com / LearnBoost / stylus）
• smoosh（https // github.com / fat / smoosh）
  …虽然我正在研究咕unt声（https // github.com / cowboy / grunt）
• 控制台跟踪（//github.com/LearnBoost/console-trace）。

不，我不使用coffeescript。

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

（对怪异的链接很抱歉，我太多了n00b的堆栈溢出，让我发布这么多）

我们使用＃3的以下变体：创建仅JSON的REST API服务器。制作一个HTML网站服务器。与您的变体一样，HTML Web服务器不是REST API服务器的客户端。相反，两者是对等的。在地下不远处，有一个内部API提供了两个服务器所需的功能。

我们尚无任何先例，因此只是一种实验。到目前为止（即将进入Beta版），它的效果非常好。

我通常会选择第二个选项，使用Rails来构建API和JS的主干。您甚至可以使用ActiveAdmin免费获得管理面板。我已经用这种后端交付了数十个移动应用程序。但是，这在很大程度上取决于您的应用程序是否是交互式的。

我在最后的RubyDay.it上做了有关此方法的演示：http : //www.slideshare.net/matteocollina/enter-the-app-era-with-ruby-on-rails-rubyday

对于第三个选项，为了获得第二个选项的响应性，您可能希望像Github一样尝试使用pajax。

我花了大约2个月的时间来进行为期3个月的项目，该项目采用了您在此处概述的第二种方法。我们使用RESTful API服务器端，并在其前端带有ribs.js。Handlebars.js管理模板，而jQuery处理AJAX和DOM操作。对于较旧的浏览器和搜索蜘蛛，我们退回到服务器端渲染，但是我们使用的是与Mozilla Rhino使用的Handlebars前端相同的HTML模板。

我们出于多种不同的原因选择了这种方法，但由于尚未得到广泛的证明，因此非常危险。都一样，到目前为止一切都进行得很顺利。

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

在选择此基础结构时，使项目的这两部分完全独立地运作是一个关键考虑因素。如果您正在寻找一种架构来融合不同的独立资源而没有任何依赖关系，那么这种方法值得一看。

恐怕我不是Ruby专家，所以我无法对其他方法发表评论。有时候冒险是可以的。其他时候最好安全一点。您将根据项目类型来了解自己。

祝您一切顺利！热衷于看看别人也分享了什么。

当我的网站不会成为我的数据的100％CRUD实现时，我喜欢＃3。这还没有发生。

我更喜欢sinatra，它将只是将应用程序分成几个具有不同用途的不同机架应用程序。我将制作一个特定于API的机架应用程序，该应用程序将涵盖我对API的需求。然后，也许一个用户机架应用程序将显示我的网页。有时，该版本会在需要时查询API，但通常只涉及html站点。

我不用担心，如果需要的话，可以从用户端进行持久层查询。我并不太在意创建一个完全的分隔，因为它们通常最终会达到不同的目的。

这是使用多个机架应用程序的非常简单的示例。我在其中添加了一个快速的jquery示例，以供您查看它在API应用程序中的作用。您可以看到使用sinatra并安装具有不同用途的多个机架应用程序有多么简单。

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

这里已经有一些不错的答案-我肯定会推荐＃2或＃3-这种分离在概念上还是在实践中都很好。

很难预测API上的负载和流量模式之类的情况，并且我们看到独立提供API的客户可以更轻松地进行配置和扩展。如果您必须将其与人工Web访问模式结合在一起，那么它就不那么容易了。同样，您的API使用率最终可能会比Web客户端更快地扩展，然后您可以看到将您的精力指向何处。

在＃2＃3之间，这实际上取决于您的目标-我同意＃2可能是webapp的未来-但是，如果该渠道只是众多渠道中的一员，也许您想要更简单的方法！

对于atyourservice.com.cy，我们使用页面的服务器端呈现模板，尤其是覆盖了这部分。并在页面加载后使用API​​进行交互。由于我们的框架是MVC，因此所有控制器功能都复制到json输出和html输出。模板是干净的，仅接收一个对象。可以在几秒钟内将其转换为js模板。我们始终维护服务器端模板，并且仅根据请求重新转换为js。

同构渲染和渐进增强。我认为这是您在选项三中的目标。

同构渲染意味着使用与客户端代码中相同的模板来生成服务器端标记。选择具有良好服务器端和客户端实现的模板语言。为您的用户创建完全烘焙的html，然后将其发送出去。也使用缓存。

渐进增强功能意味着下载完所有资源并确定客户端功能后，便开始执行客户端执行，渲染和事件监听。尽可能回退到无客户端脚本功能，以实现可访问性和向后兼容性。

是的，当然要为此应用程序功能编写一个独立的json api。但是不要走得太远，您不能为静态html文档可以正常工作的情况写一个json 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 Core Team正在开发FastBoot，它使您可以在服务器端（特别是node.js）执行JavaScript Ember逻辑，并将应用程序的预渲染HTML（通常在浏览器中运行）发送给用户。SEO和用户体验非常好，因为他不需要等待很长时间即可显示页面。

Ember CLI是一个很棒的工具，可以帮助您组织代码，并且可以随着代码库的扩展而很好地扩展。Ember也有自己的插件生态系统，您可以从各种Ember Addons中进行选择。您可以轻松获取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的示例，还有许多使用它的客户端。

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

这样做的优点是API服务器可以独立于Web服务器进行扩展。如果您有多个客户端，则网站将不需要扩展到与Web服务器相同的程度，因为某些客户端将基于电话/平板电脑或台式机。

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

这是一个非常好的问题，我感到很惊讶，因为我认为这是当今非常常见的任务，因此我将拥有大量的资源来解决该问题，但是事实证明这并非事实。

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

我采用了一种混合方法，其中我们以Sinatra为基础，使用ActiveRecord / Postgress等来提供页面路由（超薄模板），公开了Web应用程序可以使用的REST API。在早期的开发中，诸如填充选择选项之类的事情是通过将助手渲染到苗条模板中来完成的，但是随着我们开始生产，随着我们开始更多地关心页面加载速度等等，它被交换为对REST API的AJAX调用。

用Slim易于呈现的东西就是用这种方式处理的，并且东西（填充表单，从jQuery接收表单POST数据，Validation的submitHandler等等，显然都是AJAX）

测试是一个问题。现在，我很想尝试将JSON数据传递到Rack :: Test POST test。

我个人更喜欢选项（3）作为解决方案。我以前的（家庭主名）雇主拥有的几乎所有场所都使用了该工具。这意味着您可以让一些前端开发人员了解Javascript，浏览器怪癖和其他方面的知识，从而为您的前端编写代码。他们只需要知道“ curl xyz，您就会得到一些json”，然后他们就走了。

同时，您的重量级后端人员可以对Json提供程序进行编码。这些家伙根本不需要考虑呈现，而担心后端不稳定，超时，优美的错误处理，数据库连接池，线程和扩展等。

选项3为您提供了一个良好而坚实的三层体系结构。这意味着您从前端吐出的内容是SEO友好的，可以使其与旧的或新的浏览器（以及那些已关闭JS的浏览器）一起使用，并且如果需要，仍可以是Javascript客户端模板（因此您可以做诸如使用静态HTML处理旧浏览器/ googlebot的事情，但向使用最新Chrome浏览器或其他工具的用户发送JS构建的动态体验。

在所有我见过的方案3中，它都是一些PHP的自定义实现，在项目之间并不是特别可移植的，更不用说进入开源领域了。我猜想最近的PHP可能已经被Ruby / Rails取代了，但是同样的事情仍然适用。

FWIW，$ current_employer可以在几个重要位置使用选项3。我正在寻找一个好的Ruby框架来构建内容。我确定我可以将大量的宝石粘合在一起，但是我更喜欢一种产品，它可以广泛提供模板，“卷曲”，可选身份验证，可选的memcache / nosql连接缓存解决方案。在那里我找不到任何一致的:-(

在Rails中构建JSON API是第一类，JSONAPI :: Resources gem为http://jsonapi.org规范的API带来了沉重的负担。