单独的REST JSON API服务器和客户端？
我即将从头开始创建一系列网络应用程序。 （请参阅http://50pop.com/code的概述。）我希望他们能够从许多不同的客户端访问：前端网站，智能手机应用程序，后端Web服务等。所以我真的很想每个JSON REST API。
另外，我更喜欢在后端工作，所以我做了白日梦，将我的注意力全部集中在API上，并雇用其他人来制作前端UI，无论是网站，iPhone，Android还是其他应用。
请帮我决定我应该采取哪种方法：
在轨道上
制作一个非常标准的Rails网络应用程序。 在控制器中，执行respond_with开关，以提供JSON或HTML。 JSON响应是我的API。
Pro：很多先例。 伟大的标准和许多以这种方式做事的例子。
Con：不一定希望API与Web应用程序相同。 不喜欢if / thenresponse_with切换方法。 混合两种截然不同的东西（UI + API）。
REST SERVER + JAVASCRIPT-HEAVY客户端
制作仅JSON的REST API服务器。 使用Backbone或Ember.js用于客户端JavaScript，直接访问API，在浏览器中显示模板。
Pro：我喜欢API和客户端的分离。 聪明的人说这是要走的路。 理论上很好。 似乎前沿和令人兴奋。
Con：先例不多。 这样做的例子并不多。 公共示例（twitter.com）感觉迟缓并且甚至不采用这种方法。
REST SERVER + SERVER-SIDE HTML客户端
制作仅JSON的REST API服务器。 制作一个基本的HTML网站客户端，只能访问REST API。 较少的客户端JavaScript。
Pro：我喜欢API和客户端的分离。 但提供纯HTML5是相当简单的，而不是客户密集型的。
Con：先例不多。 这样做的例子并不多。 框架也不支持这一点。 不知道如何处理它。
特别是从经验中寻找建议，而不仅仅是理论上的。
在Boundless，我们已经深入了解选项＃2并将其推广给成千上万的学生。 我们的服务器是JSON REST API（Scala + MongoDB），我们所有的客户端代码都是直接从CloudFront提供的（例如：www.boundless.com只是CloudFront的别名）。
优点：
缺点：
我确实认为这是所有网络应用程序的未来。
对网络前端人员的一些想法（这是所有新/挑战都来自这种架构的地方）：
我们已经为我们的前端开发构建了一个名为'Spar'（单页应用程序Rocketship）的线索，它实际上是Rails针对单页应用程序开发进行调整的资产管道。 我们将在接下来的几周内在我们的github页面上开放采购，并附上博客文章，更详细地解释如何使用它和整体架构。
更新：
关于人们对Backbone的担忧，我认为他们的评价过高。 骨干远不止是一个深层框架，而是更多的组织原则。 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请求代码。
这实际上并不像前端那样困难。 API调用和结果数据（主要是json）可用于您的客户端模板或MVC。
较少的服务器端处理。 这意味着你可以购买商品硬件/价格较低的服务器。
更容易独立地测试图层，更容易生成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可能会发现它有用。
我的结论和建议
选项3 !.
所有说，我已经成功地使用了选项2，但现在倾向于选项3为简单起见。 使用构建脚本生成静态HTML页面并使用专门提供静态页面的超高速服务器提供服务非常诱人（选项2）。
建设gaug.es时，我们选择了＃2。 我从事API（ruby，sinatra等）和我的业务合作伙伴史蒂夫史密斯（Steve Smith）开发了前端（JavaScript客户端）。
优点：
平行移动。 如果我在Steve之前工作，我可以继续为新功能创建API。 如果他在我之前工作，他可以非常容易地伪装API并构建UI。
API免费。 开放访问您应用中的数据正在迅速成为标准功能。 如果你从头开始使用API，你可以免费获得这个API。
清洁分离。 最好将您的应用程序视为客户端的API。 当然，第一个也是最重要的客户端可能是网络客户端，但它可以让您轻松创建其他客户端（iPhone，Android）。
缺点：
我现在不能再想到任何缺点了。
结论：如果您打算发布一个API，API + JS客户端就是要走的路。
PS我也建议在发布之前完整记录您的API。 记录Gaug.es API的过程确实为我们提供了帮助
http://get.gaug.es/documentation/api/
链接地址: http://www.djcxy.com/p/1229.html