我要从头开始创建一堆网络应用程序。(详见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是非常简单的，而且不是客户密集型的。
弊:没有太多先例。这方面做得好的例子不多。框架也不支持这一点。不知道该怎么处理。
尤其是从经验中寻求建议，而不仅仅是理论上的建议。
一个非常好的问题，我很惊讶，因为我认为这是一个非常普遍的任务，现在我会有足够的资源来解决这个问题，然而事实并非如此。
我的想法如下:
-创建一些在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
我喜欢#3，当我的网站不是100%的CRUD实现我的数据。这种情况尚未发生。
我更喜欢sinatra，只会把应用程序分成几个不同的机架应用程序与不同的目的。我会做一个API特定的机架应用程序，将涵盖我需要的API。然后可能是一个用户机架应用程序，将呈现我的网页。有时该版本会在需要时查询API，但通常它只关心html站点。
我不担心它，只要从用户端做一个持久化层查询，如果我需要它。我不太关心创建一个完全的分离，因为他们通常最终服务于不同的目的。
下面是一个使用多个机架应用程序的简单示例。我在那里添加了一个jquery的快速示例，让你看到它击中API应用程序。你可以看到sinatra和安装多个不同用途的机架应用程序是多么简单。
https://github.com/dusty/multi-rack-app-app
REST服务器+ javascript为主的客户端是我在最近的工作中遵循的原则。
REST服务器是在node.js + Express + MongoDB(非常好的写作性能)+ Mongoose ODM(非常适合建模数据，包括验证)+ CoffeeScript(我现在用ES2015代替)中实现的，这对我来说很好。与其他可能的服务器端技术相比，Node.js可能相对年轻，但它使我能够编写集成了支付的可靠API。
我使用Ember.js作为JavaScript框架，大部分应用程序逻辑是在浏览器中执行的。我使用SASS(特别是SCSS)进行CSS预处理。
Ember是由强大的社区支持的成熟框架。它是一个非常强大的框架，最近有很多工作都集中在性能上，比如全新的Glimmer渲染引擎(灵感来自React)。
Ember核心团队正在开发FastBoot，它可以让你在服务器端(node.js具体)执行你的JavaScript Ember逻辑，并发送预渲染的应用程序HTML(通常在浏览器中运行)给用户。这是伟大的搜索引擎优化和用户体验，因为他不会等待那么长时间的页面显示。
Ember CLI是一个很好的工具，可以帮助你组织你的代码，它在不断增长的代码库中做得很好。烬也有它自己的插件生态系统，你可以选择从各种烬插件。你可以很容易地抓取Bootstrap(在我的情况下)或Foundation，并将其添加到你的应用程序。
不是通过Express来提供所有的服务，我选择使用nginx来提供图像和javascript较多的客户端。使用nginx代理在我的情况下是有帮助的:
upstream app_appName.com {
# replace 0.0.0.0 with your IP address and 1000 with your port of node HTTP server
server 0.0.0.0:1000;
keepalive 8;
}
server {
listen 80 default_server;
listen [::]:80 default_server ipv6only=on;
client_max_body_size 32M;
access_log /var/log/nginx/appName.access.log;
error_log /var/log/nginx/appName.error.log;
server_name appName.com appName;
location / {
# frontend assets path
root /var/www/html;
index index.html;
# to handle Ember routing
try_files $uri $uri/ /index.html?/$request_uri;
}
location /i/ {
alias /var/i/img/;
}
location /api/v1/ {
proxy_pass http://app_appName.com;
proxy_next_upstream error timeout invalid_header http_500 http_502
http_503 http_504;
proxy_redirect off;
proxy_buffering off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
利:我喜欢API和客户端的分离。聪明的人说这是
该走的路。理论上很好。看起来很前卫，令人兴奋。
我可以说它在实践中也很好。分离REST API的另一个优点是，以后可以在其他应用程序中重用它。在理想的情况下，你不仅可以在网页上使用相同的REST API，如果你决定编写一个移动应用程序，也可以在移动应用程序上使用。
弊:没有太多先例。这方面做得好的例子不多。公共
例子(twitter.com)感觉迟钝，甚至切换
这种方法。
现在情况看起来不一样了。有很多使用REST API +许多客户端使用它的例子。
