同构渲染和渐进增强。这也是你选择第三个选项的原因。

同构呈现意味着使用与在客户端代码中使用的相同模板来生成服务器端标记。选择具有良好的服务器端和客户端实现的模板语言。为您的用户创建完全烘烤的html并将其发送到线上。也要使用缓存。

渐进式增强意味着一旦下载了所有资源，就可以开始执行客户端执行、呈现和事件监听，并确定客户端功能。为了可访问性和向后兼容性，尽可能使用无功能客户端脚本的功能。

是的，当然要为这个应用程序功能编写一个独立的json api。但不要太过分，为静态html文档那样工作得很好的东西编写json api。

我的3个月项目已经进行了2个月，采用了你在这里概述的第二种方法。我们使用一个RESTful API服务器端，前端是backbone.js。js管理模板，jQuery处理AJAX和DOM操作。对于旧的浏览器和搜索蜘蛛，我们已经退回到服务器端渲染，但是我们使用的是与使用Mozilla Rhino的Handlebars前端相同的HTML模板。

我们选择这种方法有很多不同的原因，但我们非常清楚，因为它还没有在大范围内得到证明，所以它有点冒险。尽管如此，到目前为止一切都进行得很顺利。。

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

让项目的这两个部分彼此完全独立是选择这个基础设施的关键考虑因素。如果您正在寻找一种架构，可以在没有任何依赖的情况下混搭不同的独立资源，那么这种方法值得一试。

恐怕我不是Ruby的人，所以我不能评论其他方法。有时候冒险一下是可以的。其他时候最好谨慎行事。你会根据项目的类型来了解自己。

祝你选对了。也热衷于看别人分享什么。

这里已经有一些很好的答案了——我肯定会推荐第2条或第3条——分离在概念上很好，在实践中也很好。

很难预测API上的负载和流量模式等事情，而我们看到的那些独立为API提供服务的客户更容易进行配置和扩展。如果你必须在人类的网络访问模式中做到这一点，那就不那么容易了。此外，你的API使用可能会比你的web客户端增长得更快，然后你就可以看到你的努力方向了。

在#2 #3之间，这真的取决于你的目标-我同意#2可能是web应用程序的未来-但也许你想要一些更直接的东西，如果那个频道只是众多频道中的一个!

同构渲染和渐进增强。这也是你选择第三个选项的原因。

同构呈现意味着使用与在客户端代码中使用的相同模板来生成服务器端标记。选择具有良好的服务器端和客户端实现的模板语言。为您的用户创建完全烘烤的html并将其发送到线上。也要使用缓存。

渐进式增强意味着一旦下载了所有资源，就可以开始执行客户端执行、呈现和事件监听，并确定客户端功能。为了可访问性和向后兼容性，尽可能使用无功能客户端脚本的功能。

是的，当然要为这个应用程序功能编写一个独立的json api。但不要太过分，为静态html文档那样工作得很好的东西编写json api。

在Rails中构建JSONAPI是一流的，JSONAPI::Resources gem为http://jsonapi.org指定的API做了繁重的工作。

我采用了一种混合的方法，我们使用Sinatra作为基础，ActiveRecord / Postgress等来提供页面路由(细长模板)，公开web应用程序可以使用的REST API。在早期的开发中，像填充选择选项这样的事情是通过helper渲染到精简模板中完成的，但当我们接近生产时，这就变成了对REST API的AJAX调用，因为我们开始更关心页面加载速度等等。

在Slim中很容易渲染出来的东西以这种方式处理，而东西(填充表单，从jQuery接收表单POST数据。验证的submitHandler等显然都是AJAX)

测试是一个问题。现在我正试图将JSON数据传递给Rack::Test POST测试。