我要从头开始创建一堆网络应用程序。(详见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是非常简单的,而且不是客户密集型的。
弊:没有太多先例。这方面做得好的例子不多。框架也不支持这一点。不知道该怎么处理。
尤其是从经验中寻求建议,而不仅仅是理论上的建议。
问得好。+ 1。当然,这对我将来是一个有用的参考。此外,@Aaron和其他人也为讨论提供了价值。
和Ruby一样,这个问题同样适用于其他编程环境。
我使用了前两个选项。第一个用于许多应用程序,第二个用于我的开源项目Cowoop
选项1
这无疑是最受欢迎的一个。但我发现实现是非常http的。每个API的初始代码都用于处理请求对象。所以API代码不仅仅是纯粹的ruby/python/其他语言代码。
Option 2
I always loved this.
This option also implies that HTML is not runtime generated on server. This is how option 2 is different from option 3. But are build as static html using a build script. When loaded on client side these HTML would call API server as JS API client.
Separation of concerns is great advantage. And very much to your liking (and mine) backend experts implement backend APIs, test them easily like usual language code without worrying about framework/ http request code.
This really is not as difficult as it sounds on frontend side. Do API calls and resulting data (mostly json) is available to your client side template or MVC.
Less server side processing. It means you may go for commodity hardware/ less expensive server.
Easier to test layers independently, easier to generate API docs.
It does have some downsides.
Many developers find this over engineered and hard to understand. So chances are that architecture may get criticized.
i18n/l10n is hard. Since HTML is essentially generated build time are static, one needs multiple builds per supported language (which isn't necessarily a bad thing). But even with that you may have corner cases around l10n/i18n and need to be careful.
Option 3
Backend coding in this case must be same as second option. Most points for option 2 are applicable here as well.
Web pages are rendered runtime using server side templates. This makes i18n/l10n much easier with more established/accepted techniques. May be one less http call for some essential context needed for page rendering like user, language, currency etc. So server side processing is increased with rendering but possibly compensated by less http calls to API server.
Now that pages are server rendered on server, frontend is now more tied with programming environment. This might not be even a consideration for many applications.
Twitter的情况下
据我所知,Twitter可能会在服务器上进行初始页面渲染,但对于页面更新,它仍然有一些API调用和客户端模板来操作DOM。所以在这种情况下,你需要维护两个模板,这增加了一些开销和复杂性。不是每个人都能负担得起这个选项,不像Twitter。
我们的项目Stack
我碰巧使用Python。我使用JsonRPC 2.0代替REST。我建议使用REST,尽管出于各种原因我喜欢JsonRPC的想法。我使用下面的库。考虑选项2/3的人可能会觉得有用。
一个快速的web微框架- Flask
前端服务器:Nginx
客户端MVC: Knockout.js
其他相关工具/库:
Jquery
js代表货币
Webshim:跨浏览器填充
director:客户端路由
生成HTML
我的结论和建议
选项3 !
总之,我已经成功地使用了选项2,但现在为了简单起见,我倾向于选项3。使用构建脚本生成静态HTML页面,并使用专门提供静态页面的超高速服务器提供这些页面是非常诱人的(选项2)。
我个人更倾向于选择(3)作为解决方案。我的前雇主(家喻户晓的名字)几乎所有的网站都在使用它。这意味着你可以找一些了解Javascript、浏览器特性等的前端开发人员来编写你的前端代码。他们只需要知道“curl xyz,你会得到一些json”,然后他们就开始了。
同时,你的重量级后端人员可以编写Json提供程序。这些人根本不需要考虑表示,而是担心零散的后端、超时、优雅的错误处理、数据库连接池、线程和扩展等。
选项3为您提供了一个良好、可靠的三层架构。这意味着你从前端输出的东西是SEO友好的,可以用于旧的或新的浏览器(以及那些关闭了JS的浏览器),如果你愿意,仍然可以是Javascript客户端模板(所以你可以用静态HTML处理旧的浏览器/googlebot,但将JS构建的动态体验发送给使用最新Chrome浏览器或其他浏览器的人)。
在我看到的所有情况下,选项3都是一些PHP的自定义实现,不能在项目之间特别转换,更不用说开源领域了。我猜最近PHP可能已经被Ruby/Rails取代了,但同样的事情仍然是正确的。
FWIW, $current_employer可以在几个重要的地方使用选项3。我正在寻找一个好的Ruby框架来构建一些东西。我确信我可以把一大堆宝石粘在一起,但我更喜欢一个广泛提供模板、“卷曲”、可选身份验证、可选memcache/nosql连接缓存解决方案的单一产品。这里我找不到任何有条理的东西:-(
问得好。+ 1。当然,这对我将来是一个有用的参考。此外,@Aaron和其他人也为讨论提供了价值。
和Ruby一样,这个问题同样适用于其他编程环境。
我使用了前两个选项。第一个用于许多应用程序,第二个用于我的开源项目Cowoop
选项1
这无疑是最受欢迎的一个。但我发现实现是非常http的。每个API的初始代码都用于处理请求对象。所以API代码不仅仅是纯粹的ruby/python/其他语言代码。
Option 2
I always loved this.
This option also implies that HTML is not runtime generated on server. This is how option 2 is different from option 3. But are build as static html using a build script. When loaded on client side these HTML would call API server as JS API client.
Separation of concerns is great advantage. And very much to your liking (and mine) backend experts implement backend APIs, test them easily like usual language code without worrying about framework/ http request code.
This really is not as difficult as it sounds on frontend side. Do API calls and resulting data (mostly json) is available to your client side template or MVC.
Less server side processing. It means you may go for commodity hardware/ less expensive server.
Easier to test layers independently, easier to generate API docs.
It does have some downsides.
Many developers find this over engineered and hard to understand. So chances are that architecture may get criticized.
i18n/l10n is hard. Since HTML is essentially generated build time are static, one needs multiple builds per supported language (which isn't necessarily a bad thing). But even with that you may have corner cases around l10n/i18n and need to be careful.
Option 3
Backend coding in this case must be same as second option. Most points for option 2 are applicable here as well.
Web pages are rendered runtime using server side templates. This makes i18n/l10n much easier with more established/accepted techniques. May be one less http call for some essential context needed for page rendering like user, language, currency etc. So server side processing is increased with rendering but possibly compensated by less http calls to API server.
Now that pages are server rendered on server, frontend is now more tied with programming environment. This might not be even a consideration for many applications.
Twitter的情况下
据我所知,Twitter可能会在服务器上进行初始页面渲染,但对于页面更新,它仍然有一些API调用和客户端模板来操作DOM。所以在这种情况下,你需要维护两个模板,这增加了一些开销和复杂性。不是每个人都能负担得起这个选项,不像Twitter。
我们的项目Stack
我碰巧使用Python。我使用JsonRPC 2.0代替REST。我建议使用REST,尽管出于各种原因我喜欢JsonRPC的想法。我使用下面的库。考虑选项2/3的人可能会觉得有用。
一个快速的web微框架- Flask
前端服务器:Nginx
客户端MVC: Knockout.js
其他相关工具/库:
Jquery
js代表货币
Webshim:跨浏览器填充
director:客户端路由
生成HTML
我的结论和建议
选项3 !
总之,我已经成功地使用了选项2,但现在为了简单起见,我倾向于选项3。使用构建脚本生成静态HTML页面,并使用专门提供静态页面的超高速服务器提供这些页面是非常诱人的(选项2)。
一个非常好的问题,我很惊讶,因为我认为这是一个非常普遍的任务,现在我会有足够的资源来解决这个问题,然而事实并非如此。
我的想法如下:
-创建一些在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