我要从头开始创建一堆网络应用程序。(详见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/

其他回答

在创建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/

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

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

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

我们使用#3的以下变体: 制作一个JSON-only REST API服务器。制作一个HTML网站服务器。HTML web服务器不是REST API服务器的客户端。相反,这两家公司是同行。在表面下不远的地方,有一个内部API提供两个服务器所需的功能。

我们不知道有任何先例,所以这是一种实验。到目前为止(即将进入测试阶段),它的效果相当不错。

我决定对Infiniforms采用选项2的体系结构,因为它提供了一种将UI与业务逻辑分离的好方法。

这样做的一个优点是API服务器可以独立于web服务器进行扩展。如果你有多个客户端,那么网站就不需要像web服务器那样扩展,因为一些客户端是基于手机/平板电脑或桌面的。

这种方法还为您向用户开放API提供了良好的基础,特别是当您使用自己的API为您的网站提供所有功能时。

对于atyourservice.com.cy,我们使用服务器端渲染的页面模板,特别是覆盖se部分。并在页面加载后使用API进行交互。 由于我们的框架是MVC,所有控制器函数都复制到json输出和html输出。模板是干净的,只接收一个对象。这可以在几秒钟内转换为js模板。我们总是维护服务器端模板,并在请求时重新转换为js。