REST当中为什么要使用HTTP PUT

REST(Representational State Transfer)是网络服务接口的一种风格，并不是一个标准，就web service而言，REST要比SOAP（SOAP是标准，不是风格）轻量得多，容易得多。我记得我最初开始接触web service的时候，所有的材料上来就是一大堆的名词，SOAP, WSDL,看得头都要大了，后来提出来的REST就容易理解得多，虽然目前SOAP在企业级的web service中还有一席之地，但是在公共的Internet上，不是REST的服务实在不好意思和人打招呼，我们经常可以看到评价某某服务是RESTful的，但是从来没有听说某某服务是SOAPful的 :-)
微软对REST的支持有点晚，自.NET3.5开始，WCF也可以提供RESTful接口。当然，REST不光限于web service，网页服务也可以RESTful，微软的ASP.NET MVC框架提供了直接的REST支持。

因为REST只是风格，不是标准，所以有的方面容易有误解，比如说创建和更新某个URI代表的资源的时候，是用HTTP的PUT还是POST命令。REST常用的四种HTTP命令，GET、DELETE、PUT和POST，对于GET和DELETE，一个是获取资源，一个是删除资源，没什么异议，问题是PUT和POST，两者都有更改指定URI的语义，那么，究竟是用哪一个呢？

有的观点认为，应该用POST来创建一个资源，用PUT来更新一个资源；有的观点认为，应该用PUT来创建一个资源，用POST来更新一个资源；还有的观点认为可以用PUT和POST中任何一个来做创建或者更新一个资源。这些观点都只看到了风格，争论起来也只是争论哪种风格更好，其实，用PUT还是POST，不是看这是创建还是更新资源的动作，这不是风格的问题，而是语义的问题。

REST是一种风格，但是还是依赖于HTTP协议，在HTTP中，PUT被定义为idempotent的方法，POST则不是，这是一个很重要的区别。

“Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request.”

上面的话就是说，如果一个方法重复执行多次，产生的效果是一样的，那就是idempotent的。

举一个简单的例子，加入由一个博客系统提供一个Web API，模式是这样http://superblogging/blogs/post/{blog-name}，很简单，将{blog-name}替换为我们的blog名字，往这个URI发送一个HTTP PUT或者POST请求，HTTP的body部分就是博文，这是一个很简单的REST API例子。我们应该用PUT方法还是POST方法？取决于这个REST服务的行为是否是idempotent的，假如我们发送两个http://superblogging/blogs/post/Sample请求，服务器端是什么样的行为？如果产生了两个博客帖子，那就说明这个服务不是idempotent的，因为多次使用产生了副作用了嘛；如果后一个请求把第一个请求覆盖掉了，那这个服务就是idempotent的。前一种情况，应该使用POST方法，后一种情况，应该使用PUT方法。

也许你会觉得这个两个方法的差别没什么大不了的，用错了也不会有什么问题，但是你的服务一放到internet上，如果不遵从HTTP协议的规范，就可能给自己带来麻烦。比如，没准Google Crawler也会访问你的服务，如果让一个不是indempotent的服务可以用indempotent的方法访问，那么你服务器的状态可能就会被Crawler修改，这是不应该发生的。