有关REST

关注REST说起来，应该是很长时间了，还读过Roy Thomas Fielding博士的那篇论文（中文版），但是对于rest的应用还是很少的，主要和现在的一些基础建设有关，最主要还是受限于开发模式和人的思维。人们已经习惯了传统的MVC模式，要跳出这个模式，是困难的。（REST已经有JCP标准和几个实现，Spring MVC是其中一个）

在REST里，最重要的一步是，做资源抽象，整个REST就是围绕资源来的。退回到最初的互联网，只有静态页面的时候，这时资源是清晰的，但操作只有GET。对于一个资源来说，GET,POST,DELETE,PUT四种方法似乎是够了，但对于传统的MVC来说，是远远不够的，客户的需要都抽象成一个个的操作，而REST里，就需要重新发现资源。例如在登录上，对于mvc是login和logout。而rest的GET,POST,DELETE,PUT和这个不搭调。那么如果这样，抽象会话为资源/session，对/session做POST和DELETE，这样就正好对应了功能上的登录和注销。

其实对于REST，我最欣赏的是它所描述的，资源和URL的对应性，不变性。后台不管采用什么技术，URL都使用REST风格的话，那么可以做到任意的技术切换，而URL永远有效。这点上和域名其实是一个道理。服务器的IP，经常是变动的，而采用域名后，通过域名解析，这样可以很容易的切换IP，做服务器切换和迁移。最理想的是，今天我的论坛是用ASP实现的，后天是用PHP实现的，由于采用REST，所以你收藏夹里所有URL都是还是有效的。

其实想到这些，还是因为在看公式权限框架时想到的。现在公司有很多机制，这些机制大多数是通过url嵌入进来的，由于机制是对公的，所有模块都能调用，这样所有调用，都必须带上上模块标识甚至是文档标识才行。这样的情况下，权限虽然能做，但还是有些不便的情况。附件下载就是最典型的。在附件下载的时候，我们常只用ID来指定要下载的附件，同时服务器会根据当前附件存在服务器的信息来判断权限。这个判断就写得比较死，只能根据默认规则来，导致模块部署附件后，没办法真正去替换附件的权限，只能接受唯一的规则。其实作为机制来说，模块需要的是复用机制的功能，而其他权限之类的就不一定要复用了。增多不同的应用，对于这种机制的使用，都有这自己的独特的方式，甚至是定义调用的规则。而且当前很多机制都配置了一个角色，模块中要使用这个功能，还得分配这个机制角色给用户，相当不便，其实对于用户来说，正对模块给权限就好了，结果我还得理解这个模块的一些功能和机制有什么关系。如果模块里有两个评论，一个是机制，一个不是，那么不直接晕倒了？

两者风格下，机制调用方式的对比
/comment.do?method=add&modelName=blog&modelId=12345
/blog/12345/comment/add （这不是真正的REST，只是一总类似风格）
相比来说，下面的REST风格更好理解，看着舒服。由于在对外表象上来说，完全是子功能的暴露，这样完全看不出来是调用的机制，而真正是一个没用动手写代码的功能。然后权限你要怎么拦截，完全是这个模块说了算。如果机制提供的功能不能满足需求，那么可以模块再开发一个同样的功能，对外URL依然可以是不变的。当然也有比较郁闷的，由于url是映射到模块上的，那么需要写代码来调用/转发请求到机制？这是个问题，要是不能省代码，机制的复用性就打折扣了。其实也有解决方法，那就是url服务器端的重写，把/blog/12345/comment/add这个请求，按照规则映射到/comment.do?method=add&modelName=blog&modelId=12345上面。这个技术也是老的MVC框架实现REST风格的有效方法。

REST风格对于当前机制还有一个好处。那就是，url的名称是有限的，也是资源，机制调用占用了/comment这对外根目录，当/comment模块本身需要要有全局功能暴露时，变得比较被动。使用rest风格/comment就可能解放了，这个可以作为全局观察所有模块调用/comment机制的监控模块。其实本质上，我们需要的复用功能，不要写代码，对于一个完整的模块，都希望所有功能就在模块上做了，不希望还要跳出去，在别的地方做点什么，再回来。对于URL来说，也是，希望看到一个更简洁漂亮的。