RESTful Web 服务四种操做POST/DELETE/PUT/GET

关于REST及RESTful的概念，已有很多文章介绍，这里整理几篇我以为不错的参考:

• 维基百科的定义: REST
• 什么是REST跟RESTful? REST理论的中文详述，其中你能够了解到WCF Restful属于RPC 样式的 Web 服务，ASP.NET Web API属于RESTful Web 服务。
• 深刻浅出REST InfoQ的专文介绍，文中甚至有Roy T. Fielding当年REST博士论文的中文翻译连接。另外值得一提的，你们可能没听过Roy Fielding的大名，但若是得知他是HTTP规格的主要做者及Apache HTTP Server项目的发起人之一，应该不会有人怀疑他在Web技术领域的份量。

上面的文章建议你们认真的读一下，这里咱们简要的介绍下REST 作入门介绍，理解整个 REST 能让咱们在 ASP.NET Web API 的路上更顺畅。

REST是什么？

REST ( REpresentational State Transfer )，State Transfer 为 "状态传输" 或 "状态转移 "，Representational 中文有人翻译为"表征"、"具象"，合起来就是 "表征状态传输" 或 "具象状态传输" 或 "表述性状态转移"，不过，通常文章或技术文件都比较不会使用翻译后的中文来撰写，而是直接引用 REST 或 RESTful 来表明，由于 REST 一整个观念，想要只用六个中文字来完整表达真有难度。

REST 一词的出于《Architectural Styles and 
the Design of Network-based Software Architectures》论文，咱们先简单从标题来看，它应该是一种架构样式 (Architectural Styles) 与软件架构 (Software Architectures)，并且是以网络 (Network-based) 为基础，重点就是：

• 架构样式 (Architectural Styles)
• 软件架构 (Software Architectures)
• 网络 (Network-based) 为基础

REST 自己是设计风格而不是标准。REST 谈论一件很是重要的事，如何正确地使用 Web标准，例如，HTTP 和 URI。想要了解 REST 最好的方式就是思索与了解 Web 及其工做方式。若是你设计的应用程序能符合 REST 原则 (REST principles)，这些符合 REST 原则的 REST 服务可称为 "RESTful web service" 也称 "RESTful Web API"。"-ful" 字尾强调它们的设计彻底符合 REST 论文里的建议内容。

资源 RESOURCE

在 REST 中的资源 (Resource) 表明整个网络上的资源。网络上提供了各式各样的资源，而网络上的资源由 URI (统一资源标识符,Uniform Resource Identifier) 来提供。 
回想，你如何连上个人 博客，你可能经过浏览器直接输入  www.cnblogs.com/shanyou 此域名来到达首页，也能用书签或网络上的连接，经点击后来连上个人博客。而后，你想看这一篇名为「REST 入门介绍」的文章，因此以你接下去点击这文章的标题连结，接去下阅读。咱们简易了解一下整个流程：

1. 经过URL ( http://www.cnblogs.com/shanyou ) ， Client 向 http://www.cnblogs.com/shanyou 发出请求
2. www.cnblogs.com/shanyou 收到请求，回应首页给 Client
3. Client 又点击 REST 文章连结  (假设是 http://www.cnblogs.com/shanyou/archive/2011/06/30/2095018.html) 向 http://www.cnblogs.com/shanyou发出archive/2011/06/30/2095018.html  此篇文章的请求
4. www.cnblogs.com/shanyou  收到请求，响应 REST 文章内容给 Client

Client 的经过 URI 来获取资源的具体象征 (Representational)。Client 取得这些具体象征使这些应用程序转变其状态 (以 浏览器而言，取得 HTML、CSS、JavaScript … 来生成界面)，随着不断取得资源的具体象征， Client 端不断地改变其状态，这样不断的反复 (iterations ) 过程就是所谓的 Representational State Transfer。

使用 WEB 标准

上述是最接近平常的范例，这些行为在 HTTP 规范中称之为 GET，也就是经过URL 来 GET 我想要的资源。另外一经常使用的例子是填写表单，例如，登入表单，我想进行登入动做，就必须先发送帐号与密码给某一资源，此资源会验证你所传送的数据是否正确，再进行后续动做。咱们发送信息给资源的行为在 HTTP 规范中称之为 POST。 
在 HTTP/1.1 RFC 2616第 5.1.1 Method 一节定义了八大类 HTTP 方法，除了咱们经常使用的 GET 与 POST 以外，在 REST 中经常使用的还有 PUT 与 DELETE。此 GET, POST, PUT, DELETE 正好能够对应咱们 CRUD (Create, Read, Update, Delete) 四种数据操做。

HTTP Method 与 CURD 数据处理操做对应
HTTP方法	数据处理	说明
POST	Create	新增一个没有id的资源
GET	Read	取得一个资源
PUT	Update	更新一个资源。或新增一个含 id 资源(若是 id 不存在)
DELETE	Delete	删除一个资源

RESTFUL WEB SERVICE

RESTful Web Service (又称 RESTful Web API) 是一个使用 HTTP 并符合 REST 原则的 Web 服务。咱们知道，经过 URL 能够传送 GET 请求，在 表单指定 method="GET|POST" 来送出请求。但咱们要处理 PUT 或 DELETE 的请求呢？经过 RESTful 咱们能够简单 URI 来定义资源并和 HTTP 方法配合使用。

Resource 与 HTTP 方法的对应
资源	资源说明	GET	PUT	POST	DELETE
http://www.cnblogs.com/Products/	Products是一组资源集合	列出 该组资源集合中每一个资源的详细信息	更新 当前整组资源	新增 或附加一个新资源。该操做传回新资源的URL	删除 整组资源
http://www.cnblogs.com/Products/1	Products/1是单个资源	取得 指定的资源的详细信息	更新 或新增指定的资源	新增 或附加一个新元素	删除 指定的元素

以上表格有没有很像咱们通常在对数据库表格的操做顺序，进入一个 Table 的数据首页 (一般是列表)，此页面会有「新增、更新、删除、详细」等连结，你想进行什么操做，就点那一个连结。 
在 RESTful 每一个资源有本身独立的 URI， Client 从资源集合或单个资源开始进入，无论是资源集合或单个资源，咱们都能与 HTTP 方法配合使用，例如，GET 下载，PUT 更新，POST 新增，DELETE 删除。

ASP.NET Web API 是一个框架(framework)，能让你在 .NET Framwork 之上架设 HTTP 服务 (HTTP Services)。ASP.NET Web API 是 .NET Framework 上构建RESTful 应用程序的理想平台。

在 Julie Lerman's 的 How I see Web API 一文中，用了一张图来简明说明 Web API：

An Introduction to ASP.NET Web API

 

GET操做是安全的。所谓安全是指无论进行多少次操做，资源的状态都不会改变。好比我用GET浏览文章，无论浏览多少次，那篇文章还在那，没有变化。固然，你可能说每浏览一次文章，文章的浏览数就加一，这不也改变了资源的状态么？这并不矛盾，由于这个改变不是GET操做引发的，而是用户本身设定的服务端逻辑形成的。

PUT，DELETE操做是幂等的。所谓幂等是指无论进行多少次操做，结果都同样。好比我用PUT修改一篇文章，而后在作一样的操做，每次操做后的结果并无不一样，DELETE也是同样。顺便说一句，由于GET操做是安全的，因此它天然也是幂等的。

POST操做既不是安全的，也不是幂等的，好比常见的POST重复加载问题：当咱们屡次发出一样的POST请求后，其结果是建立出了若干的资源。

安全和幂等的意义在于：当操做没有达到预期的目标时，咱们能够不停的重试，而不会对资源产生反作用。从这个意义上说，POST操做每每是有害的，但不少时候咱们仍是不得不使用它。

还有一点须要注意的就是，建立操做可使用POST，也可使用PUT，区别在于POST 是做用在一个集合资源之上的（/uri），而PUT操做是做用在一个具体资源之上的（/uri/xxx），再通俗点说，若是URL能够在客户端肯定，那么就使用PUT，若是是在服务端肯定，那么就使用POST，好比说不少资源使用数据库自增主键做为标识信息，而建立的资源的标识信息究竟是什么只能由服务端提供，这个时候就必须使用POST。

关于GET POST 的混淆

先说相同点，只有了解了相同点以后才能理解为何会发生混淆。二者都能向服务器发送数据，提交的“内容”[注1]的格式相同，都是var_1=value_1&var_2=value_2&....get 和 post 区别如字面，一个是get（获取），一个是post（发送）。get用来告诉服务器须要获取哪些内容（uri+query），向静态页面（uri）请求则直接返回文件内容给浏览器，向一个动态页面请求时能够提供查询参数（query）以得到相应内容。post用来向服务器提交内容，主要是为了提交，而不是为了请求内容，就是说post的初衷并不要求服务器返回内容[注2]，只是提交内容让服务器处理（主要是存储或者处理以后再存储）。get和post出现混淆是由于对提交的数据处理方法的滥用形成的，数据是无辜的。

混淆之一： 将get提交的用来查询的字段看成是存储数据存入了服务器端文件或者数据库。而后就误觉得get是用来提交用于存储的数据的。

混淆之二： 编写脚本在服务器端经过处理post提交的数据并返回内容。只要有数据，就能用来进行判断，脚本怎写是程序员的事，而不在意数据来源的形式（post、get，或者是本身预设值的常量）。这点功能上确实没问题，只是背离的其初始目的而已。

因为都是要传送数据，且数据格式相同（即便数据格式不一样，只要能提取出相应数据）。使用的时候不免出现张冠李戴，将get数据用来存储、将post数据用来检索返回数据。可是两者仍是有区别的（主要是根据其用途而“人为”[注3]形成的），get的长度限制在2048字节（由浏览器和服务器限制的，这是目前IE的数据，曾经是1024字节），很大程度上限制了get用来传递“存储数据”的数据的能力，因此仍是老老实实用来作检索吧；post则无此限制（只是HTTP协议规范没有进行大小限制，但受限于服务器的处理能力），所以对于大的数据（通常来讲须要存储的数据可能会比较大，比2048字节大）的传递有自然的优点，谁让它是 nature born post 呢。

get提交的数据是放在url里，目的是灵活的向服务其提交检索请求，能够在地址栏随时修改数据以变动须要获取的内容，好比直接修改分页的编号就跳到另一个分页了（固然也多是 404）。post提交的数据放在http请求的正文里，目的在于提交数据并用于服务器端的存储，而不容许用户过多的更改相应数据（主要是相对于在url 修改要麻烦不少，url的修改只要点击地址栏输入字符就能够了），除非是专门跑来编辑数据的。

花边：post和get的安全性在传输的层面上区别不大，可是采用url提交数据的get方式容易被人肉眼看到，或者出如今历史纪录里，仍是可能被肉眼看到，都是一些本地的问题。