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

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


当前回答

对于atyourservice.com.cy,我们使用服务器端渲染的页面模板,特别是覆盖se部分。并在页面加载后使用API进行交互。 由于我们的框架是MVC,所有控制器函数都复制到json输出和html输出。模板是干净的,只接收一个对象。这可以在几秒钟内转换为js模板。我们总是维护服务器端模板,并在请求时重新转换为js。

其他回答

同构渲染和渐进增强。这也是你选择第三个选项的原因。

同构呈现意味着使用与在客户端代码中使用的相同模板来生成服务器端标记。选择具有良好的服务器端和客户端实现的模板语言。为您的用户创建完全烘烤的html并将其发送到线上。也要使用缓存。

渐进式增强意味着一旦下载了所有资源,就可以开始执行客户端执行、呈现和事件监听,并确定客户端功能。为了可访问性和向后兼容性,尽可能使用无功能客户端脚本的功能。

是的,当然要为这个应用程序功能编写一个独立的json api。但不要太过分,为静态html文档那样工作得很好的东西编写json api。

我们使用#3的以下变体: 制作一个JSON-only REST API服务器。制作一个HTML网站服务器。HTML web服务器不是REST 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堆栈溢出让我张贴那么多)

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

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

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

我的3个月项目已经进行了2个月,采用了你在这里概述的第二种方法。我们使用一个RESTful API服务器端,前端是backbone.js。js管理模板,jQuery处理AJAX和DOM操作。对于旧的浏览器和搜索蜘蛛,我们已经退回到服务器端渲染,但是我们使用的是与使用Mozilla Rhino的Handlebars前端相同的HTML模板。

我们选择这种方法有很多不同的原因,但我们非常清楚,因为它还没有在大范围内得到证明,所以它有点冒险。尽管如此,到目前为止一切都进行得很顺利。。

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

让项目的这两个部分彼此完全独立是选择这个基础设施的关键考虑因素。如果您正在寻找一种架构,可以在没有任何依赖的情况下混搭不同的独立资源,那么这种方法值得一试。

恐怕我不是Ruby的人,所以我不能评论其他方法。有时候冒险一下是可以的。其他时候最好谨慎行事。你会根据项目的类型来了解自己。

祝你选对了。也热衷于看别人分享什么。