没有人真正理解REST or HTTP
Literate Programming - Nobody Understands REST or HTTP
这篇文章很有意思,挖掘了REST深层,特别重点指出REST的URL是名词。
比如银行转帐,从帐户1转到帐户2转去500元,那么REST URL一般人写成:
POST /accounts/1/transfer/500.00/to/2
其实错误的,因为REST中R代表Resource资源,资源是名词,你并不是在转钱,而是在创建一个转帐交易资源。应该是:
POST 资源名词 |
这个概念很有意思,我们知道DDD也是一个名词建模,在DDD中,转帐交易我们是使用一个服务来实现,当然这里的服务可以看成是一个资源。
曾经有一篇文章认为WEB天生是面向函数的,这里的“POST”可以看成是一个方法函数,而“资源名词”看成方法的参数。
将来是否有一种技术思想,将DDD REST以及面向函数三者完美捆绑一起,通过URL代表领域模型类图的结构关系,比如/forum/thread,代表Forum类的子类Thread,领域模型被显式地用URL表达出来,用户访问形式和我们分析设计的模型合二为一,大道至简。
遐想太多,回到这篇文章,作者认为这个转帐应该是创建一个转帐交易资源,改为:
POST /transactions |
然后加入参数 from=1&to=2&amount=500.00
在面向函数FP中,函数也可以看成是一个对象,对象也就是资源,在REST这里好像得到了统一。
接着作者思路,当创建了交易资源后,服务器REST端将返回:
|
返回的URL是http://foo.com/transactions/1,也就是告诉你已经成功创建了transactions这个交易,下一步你可以访问其中的/transactions/1
当REST客户端再次访问:
GET /transactions/1 HTTP/1.1
返回结果是:
HTTP/1.1 blah blah blah
{"id":1,"status":"in-progress"}
表示正在处理当中,我们可以继续访问这个URL,直至其完成或失败。这就是名词思路。
有人可能认为这个名词思路和WEB的天生函数FP有违背,实际上,REST的POST/GET等四个动作已经表明是函数,那么URL无疑代表业务名词,当然,是不是可以将URL又代表业务方法或函数呢?其实,这里transactions交易被当作资源,而交易显然是业务方法或函数。