我要从头开始创建一堆网络应用程序。(详见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是非常简单的，而且不是客户密集型的。
弊:没有太多先例。这方面做得好的例子不多。框架也不支持这一点。不知道该怎么处理。
尤其是从经验中寻求建议，而不仅仅是理论上的建议。
在创建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/
一个非常好的问题，我很惊讶，因为我认为这是一个非常普遍的任务，现在我会有足够的资源来解决这个问题，然而事实并非如此。
我的想法如下:
-创建一些在API控制器和HTML控制器之间具有公共逻辑的模块，而不返回json或呈现HTML，并将此模块包含在HTML控制器和API控制器中，然后做任何你想做的事情，例如:
module WebAndAPICommon
module Products
def index
@products = # do some logic here that will set @products variable
end
end
end
class ProductsController < ApplicationController
# default products controlelr, for rendering HMTL pages
include WebAndAPICommon
def index
super
end
end
module API
class ProductsController
include WebAndAPICommon
def index
super
render json: @products
end
end
end
我目前正致力于将一个巨大的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堆栈溢出让我张贴那么多)
