我要从头开始创建一堆网络应用程序。(详见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是非常简单的,而且不是客户密集型的。 弊:没有太多先例。这方面做得好的例子不多。框架也不支持这一点。不知道该怎么处理。

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


当前回答

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

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

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

其他回答

我个人更倾向于选择(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连接缓存解决方案的单一产品。这里我找不到任何有条理的东西:-(

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

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

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

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

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

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

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

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