单独的REST JSON API服务器和客户端？

Question

我即将从头开始创建一堆Web应用程序.(请参阅http://50pop.com/code获取概述.)我希望能够从许多不同的客户端访问它们:前端网站,智能手机应用程序,后端网络服务等.所以我真的想要一个每个JSON REST API.

此外,我更喜欢在后端工作,所以我梦想着我完全专注于API,并雇用其他人来制作前端用户界面,无论是网站,iPhone,Android还是其他应用.

请帮我决定采取哪种方法:

一起在铁路上

制作一个非常标准的Rails网络应用程序.在控制器中,执行respond_with开关,以提供JSON或HTML.然后JSON响应是我的API.

亲:很多先例.伟大的标准和许多以这种方式做事的例子.

Con:不一定要API与Web应用程序相同.不喜欢if/then respond_with切换方法.混合两个非常不同的东西(UI + API).

REST SERVER + JAVASCRIPT-HEAVY CLIENT

制作仅限JSON的REST API服务器.使用Backbone或Ember.js直接访问客户端JavaScript,在浏览器中显示模板.

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

骗局:没有多少先例.这方面的例子并不多.公共示例(twitter.com)感觉迟钝,甚至转向远离这种方法.

REST服务器+服务器端HTML客户端

制作仅限JSON的REST API服务器.创建一个基本的HTML网站客户端,仅访问REST API.减少客户端JavaScript.

亲:我喜欢API和客户端的分离.但是提供纯HTML5非常简单,而且不是客户密集型的.

骗局:没有多少先例.这方面的例子并不多.框架也不支持这一点.不知道如何处理它.

特别是从经验中寻求建议,而不仅仅是在理论上.

Answer 1

在Boundless,我们已经深入了解选项#2并将其推广到成千上万的学生.我们的服务器是一个JSON REST API(Scala + MongoDB),我们所有的客户端代码都是直接从CloudFront提供的(即:www.boundless.com只是CloudFront的别名).

优点:

• 新锐/激动人心
• 为您带来很多好处:API为您自己的Web客户端,移动客户端,第三方访问等提供了基础.
• 非常快速的网站加载/网页过渡

缺点:

• 没有SEO友好/准备没有更多的工作.
• 需要一流的网络前端用户,他们随时准备应对70%javascript网站体验的现实以及这意味着什么.

我认为这是所有网络应用程序的未来.

对Web前端人员的一些想法(这是所有新的/挑战给予这种架构的地方):

• CoffeeScript的.更容易生成高质量的代码.
• 骨干.组织逻辑和活跃社区的好方法.
• HAMLC.Haml + CoffeeScript模板=> JS.
• 上海社会科学院

我们为前端开发构建了一个称为"Spar"(单页应用程序Rocketship)的工具,它实际上是Rails为单页面应用程序开发而调整的资产管道.我们将在接下来的几周内在我们的github页面上开源,以及一篇博客文章,详细解释如何使用它和整体架构.

更新:

关于人们对Backbone的关注,我认为它们被高估了.Backbone更像是一个组织原则,而不是一个深层框架.Twitter的网站本身就是一个巨大的Javascript野兽,涵盖数百万用户和传统浏览器的每个角落,同时实时加载推文,垃圾收集,显示大量多媒体等.在我所有的'纯'js网站中看到,Twitter是奇怪的一个.通过JS提供的许多令人印象深刻的复杂应用程序非常好.

您选择的架构完全取决于您的目标.如果您正在寻找支持多个客户端并获得良好前端人才的最快方式,那么投资独立的API是一个很好的方法.

Answer 2

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

我使用了前两个选项.第一个用于众多应用程序,第二个用于我的开源项目Cowoop

选项1

这个毫无疑问是最受欢迎的.但我发现实施非常多的http-ish.每个API的初始代码都处理请求对象.所以API代码不仅仅是纯ruby/python /其他语言代码.

选项2

我一直很喜欢这个.

此选项还意味着HTML不是在服务器上生成的运行时.这是选项2与选项3的不同之处.但是使用构建脚本构建为静态html.在客户端加载时,这些HTML会将API服务器称为JS API客户端.

• 关注点分离是一个很大的优势.非常喜欢(和我的)后端专家实现后端API,像通常的语言代码一样轻松测试它们,而不用担心框架/ http请求代码.

• 这真的不像前端那样困难.API调用和结果数据(主要是json)可用于客户端模板或MVC.

• 减少服务器端处理.这意味着您可以选择商用硬件/更便宜的服务器.

• 更容易独立测试图层,更容易生成API文档.

它确实有一些缺点.

• 许多开发人员发现这个过于设计并且难以理解.所以建筑可能会受到批评.

• i18n/l10n很难.由于HTML本质上是生成的,因此构建时间是静态的,每个支持的语言需要多个构建(这不一定是坏事).但即便如此,你可能会在l10n/i18n附近遇到拐角情况,需要小心.

选项3

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

使用服务器端模板呈现网页运行时.这使得i18n/l10n更容易使用更成熟/可接受的技术.可能是少了一个HTTP调用了需要的页面渲染,如用户,语言,货币等一些必要的背景所以服务器端处理与呈现增加,但可能由少HTTP调用API服务器补偿.

既然页面是服务器上呈现的服务器,前端现在更多地与编程环境相关联.这可能甚至不是许多应用程序的考虑因素.

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).

Answer 3

我们在建造gaug.es时选择了#2.我参与了API(ruby,sinatra等),我的业务合作伙伴Steve Smith在前端(javascript客户端)工作.

优点:

1. 快速并行移动.如果我领先于Steve,我可以继续为新功能创建API.如果他在我之前工作,他可以​​非常轻松地伪造API并构建UI.

2. API免费.对应用程序中的数据进行开放式访问很快就会成为标准功能.如果您从头开始使用API​​,则可以免费获得.

3. 清洁分离.最好将您的应用视为客户端的API.当然,第一个也是最重要的客户端可能是网络客户端,但它可以帮助您轻松创建其他客户端(iPhone,Android).

缺点:

1. 向后兼容性.这与API有关,而不是直接问题,但是一旦你的API出现在那里,你就不能打破它,或者你打破所有客户两个.这并不意味着你必须放慢速度,但这确实意味着你必须经常让两件事情同时发挥作用.添加API或新字段很好,但不应在没有版本控制的情况下进行更改/删除.

我现在想不起有任何缺点.

结论:如果您计划发布API,API + JS客户端就是您的选择.

PS我还建议在发布之前完整记录您的API.记录Gaug.es API的过程确实帮助了我们

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

Answer 4

我更喜欢走#2和#3的路线.主要是因为#1违反了关注点的分离并混合了各种各样的东西.最终你会发现需要一个没有匹配的HTML页面/等的API端点,并且你将在相同的代码库中使用混合的HTML和JSON端点.它变成了一个疯狂的混乱,即使它的MVP,你将不得不重新写它最终因为它太混乱,甚至不值得打捞.

使用#2或#3可以让您完全拥有一个API,无论如何(大多数情况下)都是相同的.这提供了很大的灵活性 我还没有100%在Backbone/ember/what/etc.js上销售.我认为它很棒,但正如我们在twitter上看到的那样,这不是最佳选择.但是...... Twitter也是一家公司的巨大野兽,拥有数亿用户.因此,任何改进都会对各个业务部门的各个领域的底线产生巨大影响.我认为除了速度之外,还有更多的决定,而且他们不会让我们参与其中.但那只是我的个人意见.但是,我不打折骨干及其竞争对手.这些应用程序很好用,非常干净,响应速度很快(大部分).

第三种选择也有一些有效的诱惑力.这是我遵循帕累托原则(80/20规则)并在服务器上呈现20%的主标记(反之亦然),然后有一个漂亮的JS客户端(骨干/等)运行其余部分.您可能无法通过JS客户端与REST API进行100%通信,但如果有必要,您将做一些工作以使更好的体验.

我认为这是"依赖于"那些问题之一,答案是"它取决于"你正在做什么,你所服务的人以及你希望他们接受什么样的经历.鉴于我认为你可以决定2或3或他们的混合.

Answer 5

我们使用#3的以下变体:创建一个仅限JSON的REST API服务器.制作HTML网站服务器.与您的变体一样,HTML Web服务器不是REST API服务器的客户端.相反,这两个是同行.在表面不远处,有一个内部API,提供两个服务器所需的功能.

我们不知道任何先例,所以它是一种实验性的.到目前为止(即将进入测试版)​​,它已经很好地完成了.

Answer 6

我目前正在努力将一个巨大的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)

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

• fleck(https // github.com/trek/fleck)
• 时刻(https // github.com/timrwood/moment)
• 手写笔(https // github.com/LearnBoost/stylus)
• smoosh(https // github.com/fat/smoosh)
  ...虽然我正在调查grunt(https // github.com/cowboy/grunt)
• 控制台跟踪(//github.com/LearnBoost/console-trace).

不,我没有使用coffeescript.

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

(对不起奇怪的链接,我太多了n00b堆栈溢出让我发布那么多)

Answer 7

我通常会选择第二个选项,使用Rails构建API,以及JS的骨干.您甚至可以使用ActiveAdmin免费获得管理面板.我用这种后端运送了数十个移动应用程序.但是,这在很大程度上取决于您的应用是否具有互动性

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

对于第三个选项,为了获得第二个选项的响应,您可能想要像Github那样尝试pajax.

Answer 8

我在为期3个月的项目中大约需要2个月,这是你在这里概述的第二种方法.我们在前面使用带有backbone.js的RESTful API服务器端.Handlebars.js管理模板,jQuery处理AJAX和DOM操作.对于较旧的浏览器和搜索蜘蛛,我们已经回到服务器端渲染,但我们使用与使用Mozilla Rhino的Handlebars前端相同的HTML模板.

我们之所以选择这种方法有很多不同的原因,但我们非常清楚它有一点风险,因为它还没有得到大规模的证明.一切都相同,到目前为止一切都很顺利.

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

让这两个项目完全相互独立是选择这个基础设施的关键考虑因素.如果您正在寻找一种架构来混搭不同的独立资源而没有任何依赖性,那么这种方法值得一看.

我担心我不是Ruby人,所以我不能对其他方法发表评论.有时可以承担风险.其他时候最好安全地玩.你会根据项目的类型自己做.

祝你好运.热衷于了解其他人分享的内容.