我要从头开始创建一堆网络应用程序。(详见http://50pop.com/code)我希望他们能够从许多不同的客户端访问:前端网站,智能手机应用程序,后端web服务,等等。所以我真的想为每一个都提供一个JSON REST API。

此外,我更喜欢在后端工作,所以我幻想着我只专注于API,雇佣其他人来制作前端UI,无论是网站、iPhone、Android还是其他应用程序。

请帮助我决定我应该采取哪一种方法:

一起在铁轨上 制作一个非常标准的Rails web应用程序。在控制器中,执行respond_with开关,以提供JSON或HTML。JSON响应就是我的API。 教授:有很多先例。伟大的标准和很多这样做的例子。 缺点:不一定希望API与web应用相同。不喜欢if/then respond_with switch方法。混合两种非常不同的东西(UI + API)。

Rest服务器+ javascript重客户端 制作一个JSON-only REST API服务器。客户端JavaScript使用Backbone或Ember.js直接访问API,在浏览器中显示模板。 利:我喜欢API和客户端的分离。聪明的人说这是正确的选择。理论上很好。看起来很前卫,令人兴奋。 弊:没有太多先例。这方面做得好的例子不多。公开的例子(twitter.com)感觉很迟钝,甚至正在改变这种方法。

休息服务器+服务器端HTML客户端 制作一个JSON-only REST API服务器。做一个基本的HTML网站客户端,只访问REST API。更少的客户端JavaScript。 利:我喜欢API和客户端的分离。但是提供简单的HTML5是非常简单的,而且不是客户密集型的。 弊:没有太多先例。这方面做得好的例子不多。框架也不支持这一点。不知道该怎么处理。

尤其是从经验中寻求建议,而不仅仅是理论上的建议。


当前回答

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

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

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

其他回答

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

这里已经有一些很好的答案了——我肯定会推荐第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 +许多客户端使用它的例子。

我目前正致力于将一个巨大的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堆栈溢出让我张贴那么多)

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

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

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