[荐]RESTful Services with Erlang and Yaws
说来也巧，刚刚推荐过 InfoQ 的 The Power of Javascript 隔天就看到 InfoQ 又发了 Steve Vinoski 的一篇 RESTful Services with Erlang and Yaws ，地址在[这里]，说不得，只好再次推荐。
和 Javascript/Ajax 一样，RESTful 也是风头正劲的 buzz words 。一言以蔽之，其实质就是回归 http 协议的本质，尽量在其框架之内解决问题。首先就是要 uri 化应用本身的资源，确保一个资源只有一个 uri ，以达致简洁。其次就是在 http 协议的 GET/POST/PUT/DELETE 动词(请求方法)上做文章(与之相对应的就是用户埋在 form 中的 act/op/delete/edit/modify/change/update/… 等千奇百怪的自定义参数)，将其映射为 CRUD 的常规操作，再就是对 http 协议的 content-type 进行严格的清晰化，针对不同客户端的请求，返回不同“格式”的数据，除此之外，对于 status code 和 header 之类也做一番“依照规范”的改进。相比 post 带上一大坨自定义参数的“老旧风格”，不规范之余，也会让参数越来越冗长以及自定义的格式越来越糟糕， RESTful 风格则显然更多的发掘了 http 协议本身已经内置的潜力，可谓正本清源。
但我还有一个小小的疑问。RESTful 之中只定义了4个“动词”，如若我的应用更为另类，需要更多的“动词”，又该如何？自定义新的 HTTP Method 引入更多的自定义 Method 是否会破坏 RESTful 想要“规约简化”的本意？希望有人能够解答此疑惑。
Comments
还有啥特别的操作?
所有对资源的操作不都可以抽象成 查看,创建,编辑,删除之一吗
有什么例外?举个例子
@kk
CRUD 对于数据库应用当然是不错的抽象，但，现实应用中似乎并非只有数据库这一种应用。
比如：聊天室、竞价拍卖、股票交易……，这些隐含“有连接”概念(stateful)的应用。从实现层面，站在数据库的角度来看(如果是用数据库来实现的话)确实也可以说它有对实现数据库记录的 CRUD 动作(但假若我不是用数据库来实现的呢？)，显然这种抽象并非此类业务比较自然的抽象模型。以聊天为例，比如，可将其业务动词抽象为比较原始的：连接、发送、接收，若更复杂一些，还可以创造出 N 多种“业务动词”出来，这些和 CRUD 又该如何映射？
我的问题是：RESTful 规范只规定了4种动词(分别用4种 HTTP 方法来映射)，这4个动词是“严格规定” or “仅仅作为示例”？
“严格规定”意味着只能有这4个，因为 HTTP 1.1 的标准方法只支持8个方法，标准内的其他方法已有相对确定的含义，显然，前面已经说过，这在很多情况下都是不够用的。
“仅仅作为示例”则意味着，可以使用 HTTP 1.2 或更高版本比如 WebDav 规范之中定义过的方法，或者，用户也可以根据自己的业务需求自行定制新的 HTTP 方法，显然，这有导致 HTTP 方法大爆炸的危险，问题是，这些定制方法对于网络设备或者代理软件之类的也意味着难于处理的境地。
还有一种可能，那就是”RESTful”不适用”隐含有连接”的模型？
比如：聊天室、竞价拍卖、股票交易……，
这些已经脱离了’资源’这个范畴了,算soa方面了,需要人肉写交互代码吧
@kk
我感觉这类应用不应该是rest不适用的范畴，似乎有若干此类应用也开放了restful的接口。
刚才拉住dlee一阵猛问，很有收获，记载在下面。
“资源是一个抽象的概念，并非严格的必须是一个URL，如果操作不够，那就再构造几个新的URL来表达操作，把对于method的渴望映射到URL中。在webdav中的这种自定义method的方式，并不符合rest的原则。”
“rest的核心是操作语义的可见性，其目的是为了让应用有良好的可伸缩性。”
“http的无状态，也是从伸缩性角度的考虑。”
那么“从伸缩性的角度考虑，在rest指导下架构的应用，是否就必须是无状态的呢”或“在rest的框架内，如何处理有状态的应用？”又或者“有状态的应用如何映射为无状态的呢？”
继续思考……。
update1
“在webdav中的这种自定义method的方式，并不符合rest的原则。”——此言并不确切，fielding认可webdav的方法，restful也不限定method的数目。但，问题在于webdav自己定义的http方法可能会造成现有http支持设施的处理困难，因而出现实际应用中的问题。
也就是说，我上面的问题已经被回答了，方法不够用，那就：
A.增加方法，象 webdav 一样，但有底层设施不支持的问题(不好用)。
B.放到“社会主义初级阶段”的url里面去。但url显然会膨胀(不好看)。
这两种方法都是rest所接受的。
update2
状态有两种：连接的状态，资源的状态，二者并无直接的关联。rest考虑的是资源的状态，而极力避免连接的状态(这会在伸缩性上造成麻烦)，也就是“每次请求都是独立的(目前将其理解为，包含所有的必须信息)”，这意味着可以在任何另外一台web服务器上来处理这个请求，request本身包含处理这个请求的所需信息。而对于连接的状态，rest则旗帜鲜明的表示反对。一般而言将cookie或session都认为是不符合原则的。长连接的comet也在其列。
那么，现在的新问题是“有状态的连接”比如comet的chat应用，又要如何用rest的原则来指导其构建呢？
继续thinking…
Write a Comment