我要从头开始创建一堆网络应用程序。(详见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是非常简单的，而且不是客户密集型的。
弊:没有太多先例。这方面做得好的例子不多。框架也不支持这一点。不知道该怎么处理。
尤其是从经验中寻求建议，而不仅仅是理论上的建议。
我喜欢#3，当我的网站不是100%的CRUD实现我的数据。这种情况尚未发生。
我更喜欢sinatra，只会把应用程序分成几个不同的机架应用程序与不同的目的。我会做一个API特定的机架应用程序，将涵盖我需要的API。然后可能是一个用户机架应用程序，将呈现我的网页。有时该版本会在需要时查询API，但通常它只关心html站点。
我不担心它，只要从用户端做一个持久化层查询，如果我需要它。我不太关心创建一个完全的分离，因为他们通常最终服务于不同的目的。
下面是一个使用多个机架应用程序的简单示例。我在那里添加了一个jquery的快速示例，让你看到它击中API应用程序。你可以看到sinatra和安装多个不同用途的机架应用程序是多么简单。
https://github.com/dusty/multi-rack-app-app
在创建gauge .es时，我们选择了#2。我负责API (ruby, sinatra等)，我的业务伙伴Steve Smith负责前端(javascript客户端)。
优点:
Move quickly in parallel. If I worked ahead of Steve, I could keep creating APIs for new features. If he worked ahead of me, he could fake out the API very easily and build the UI.
API for free. Having open access to the data in your app is quickly becoming a standard feature. If you start with an API from the ground up, you get this for free.
Clean separation. It is better to think of your app as an API with clients. Sure, the first and most important client may be a web one, but it sets you up for easily creating other clients (iPhone, Android).
缺点:
向后兼容性。这与API的关系比你直接的问题更大，但一旦你的API出来了，你就不能破坏它，也不能破坏所有的客户端。这并不意味着你要放慢速度，但它确实意味着你必须经常同时做两件事。添加到API或新字段是可以的，但是在没有版本控制的情况下不应该进行更改/删除。
我现在想不出什么骗局了。
结论:如果你计划发布一个API, API + JS客户端是正确的选择。
另外，我还建议在发布API之前完整地记录它。编写gage .es API的过程确实帮助了我们进行imp操作
http://get.gaug.es/documentation/api/
在Boundless，我们已经深入研究了第2个选项，并将其推广给了数千名学生。我们的服务器是一个JSON REST API (Scala + MongoDB)，我们所有的客户端代码都是直接从CloudFront提供的(即:www.boundless.com只是CloudFront的别名)。
优点:
尖端的/令人兴奋
好处多多:API为你自己的web客户端、移动客户端、第三方访问等提供了基础。
非常快的网站加载/页面转换
缺点:
不SEO友好/准备没有更多的工作。
需要一流的web前端人员，他们准备好应对网站体验的现实，70%是javascript和这意味着什么。
我认为这是所有网络应用程序的未来。
对web前端人员的一些想法(这是这个架构所具有的所有新事物/挑战):
CoffeeScript。更容易生成高质量的代码。
骨干。组织逻辑和活跃社区的好方法。
HAMLC。Haml + CoffeeScript模板=> JS。
萨斯
我们已经为我们的前端开发构建了一个名为“Spar”(单页应用Rocketship)的工具，它实际上是Rails为单页应用开发调整的资产管道。我们将在接下来的几周内在我们的github页面上开放源代码，同时还有一篇博客文章解释如何使用它和更详细的整体架构。
更新:
With respect to people's concerns with Backbone, I think they are over-rated. Backbone is far more an organizational principle than it is a deep framework. Twitter's site itself is a giant beast of Javascript covering every corner-case across millions of users & legacy browsers, while loading tweets real-time, garbage collect, display lots of multimedia, etc. Of all the 'pure' js sites I've seen, Twitter is the odd one out. There have been many impressively complicated apps delivered via JS that fare very well.
体系结构的选择完全取决于您的目标。如果您正在寻找支持多个客户端的最快方式，并有机会接触到优秀的前端人才，那么投资一个独立的API是一个很好的方法。
