WebAPI前置知识：HTTP与RestfulAPI
HTTP
对HTTP协议的基本了解是能理解并使用RestFul风格API的基础，在了解了这些基础之后，使用各种RestFul的开发框架才能得心应手。我的理解里，RestFul风格的API即是对HTTP协议良好支持，实现HTTP完整语义风格的API。
我们首先要认识到，网站的数据交互只是HTTP使用的一个场景而已，HTTP可以传递各种形式的数据。
我们从HTTP的第一行说起：HTTP的第一行包含三个信息：谓词、URL、HTTP协议版本。三个数据使用空格隔开。
谓词：对于RestFul API来说谓词是非常重要的一个元素，WEB API就是使用谓词作为默认的路由方式，最常用的谓词有：POST\DELETE\PUT\GET，这四个谓词对应了“增、删、改、查”四个动作（POST和PUT谁是增谁是改不同资料总有不同的说法，我其实有略微有点困惑啦……有定义说PUT是幂等操作，而POST不是，那PUT就更偏重于改而POST更偏重于增）。最常用的谓词即为这四个，也有其他谓词拥有不同的语义：
HEAD：仅返回相应头部，不包含Body
TRACE：对数据传输过程进行诊断
OPTIONS：请求 Web 服务器告知其支持的各种功能
还有其他谓词，如果需要可以查询相关文档，但并不常用。
其中，GET，DELETE不包含BODY，PUT,POST可以包含BODY。而如果一个谓词包含了语义之外的操作，例如GET中带BODY，POST用于删除资源这种操作也是被允许的，称之为谓词的重载，虽然HTTP可以支持谓词的重载，但并不建议使用，因为不符合标准语义。
URL : URL定义了一个资源，例如www.example.com/person 定义了person为一个资源，结合上面所介绍的谓词，我们提供Person一组操作：
GET www.example/person/1 即获取ID为1的用户的信息
POST www.example/person/ (BODY中包含Person的描述) 创建一个Person资源
PUT www.example/person/1 (BODY中包含Person的描述) 更新一个Person资源
DELETE www.example/person/1 删除ID为1的Person资源
HTTP版本：
目前主要使用的是HTTP1.0 和 HTTP1.1协议，HTTP2.0协议正在普及阶段，用的还不是很多。HTTP1.0 和HTTP1.1区别很小，其中的差异对于RestFul来说影响并不是很大。具体的差别大家可以查询相关文档。
HTTP的第一行内容就是这些，接下来会有一个\r\n来进行换行，接下来就是HTTP HEAD部分，HTTP HEAD描述了HTTP请求和响应。我认为HTTP HEAD即为HTTP协议中最重要的部分，他包含了编码、BODY长度、内容协商等信息，你也可以包含一些自定义信息。下面我来为大家介绍几个在RestFul API中常用的HEAD:
User-Agent:用户代理，是什么客户端发出的请求，如IE、Chrome、Fiddler等
HOST:域名（HOST一般用于服务器的站点绑定，一般和URL的域名相同，但是在一些自定义的DNS使用方式中，可能会出现HOST和URL中的域名不一致）
Authorization：验证信息，这个字段可以包含一些用于用户验证的信息，而表示方法为：schema authorinfo，中间使用空格隔开，其中schema代表了验证方法，authorinfo代表了验证信息，常见的schema 如 Base：authorinfo使用用户名+密码，并用Base64进行编码。或者使用Token，类似于Session的方式。
Accept：接受何种序列化方式返回的数据，用MIME表示，用于对响应数据的内容协商，可以包含多个MIME，按优先顺序排列，如application/json，application/xml，text/html；具体服务器可以返回什么类型的数据需要由服务器支持情况而定，有一些标准MIME，可以查到；有时我们也需要一些自定义的MIME，例如bson、protocolbuffer等，我们可以自定义MIME，在服务端开发自己的实现，而这些特的扩展在ASP.NET WebApi中都有相应的扩展点。
Content-Type:使用一个MIME表示，表示所发送请求的Body的序列化方式，常见的如application/json，还有WEB交互最常使用的application/x-www-form-urlencoded，都表示了你的body部分的序列化方式，在请求、响应中都会出现
HTTP HEAD部分我认为是HTTP协议中最核心的部分，其中可配置、使用的地方实在太多太多，而且有太多的细节，以上为我列出的在我的工作中最常用的部分，介绍这些内容的资料全部列出来足够完成一本书了，大家有兴趣可以查找相关资料，在Rest API中，内容协商经常让一开始学习使用Rest的人很迷惑，一定要记住Accept，Content-Type两个头的作用和区别，Accept表示希望接受什么样的数据，Content-Type表示当前请求中Body的编码方式。在ASP.NET WEBAPI中，如果请求中有Content-Type，而没有ACCEPT，则默认使用Content-Type中的内容作为响应的内容协商。
响应部分也分为头部和Body，响应头部和请求头部最大的不同在于响应首行存在一个HTTP Code，HTTP Code作为API的调用状态的展示，也很重要，在REST API中最常用的状态码一般为2XX,4XX,5XX三个段，而1XX表示工作还要继续，3XX一般表示重定向，在REST API中使用的并不多。而在最常用的三个Status 段中，2XX表示执行成功，4XX表示客户端数据错误(例如参数校验不通过)，5XX表示服务器端处理错误，例如有未处理的异常(如数据库连接错误)，根据这些状态码可以初步判断API调用的执行状态。
在首部之后有一个空行（\r\n）接下来就是Content，这里有具体的业务数据，根据不同的Content-Type使用不同的序列化方式表示，例如JSON，XML，甚至HTML。各位在学习HTTP API时可以认为网页应用也是HTTP 的一种应用，只是交互方式一般使用application/x-www-form-urlencoded 作为请求、 text/html作为响应的方式进行交互。而RestAPI可以使用其他很多种编码方式进行交互，支持的更广，网页应用只是使用HTTP传输的一种应用场景，RestAPI和网页是可以不分开的。我觉得这一点Nancy比ASP.NET做得更好，Nancy并没有把RestAPI和网页割裂开来，而ASP.NET用MVC和WEBAPI将两者割裂了；请求一个数据，我可以要求Accept为application/json时返回Json数据，而使用text/html时返回一个网页；当然，将这两种应用方式切割或合并起来都各有优劣。
我所写的这些对于HTTP协议而言实在太少太少，大家有兴趣的可以自行查找相关资料，我只是写出了WEB API中常用的部分，下面我们来用一张图为大家展示一下这些知识：
RESTful
REST，是互联网软件的架构原则，即Representational State Transfer的缩写，是"表现层状态转化"。
如果一个架构符合REST原则，就称它为RESTful架构。
表现层
"资源"是一种信息实体，它可以有多种外在表现形式。我们把"资源"具体呈现出来的形式，叫做它的"表现层"（Representation）。
比如，文本可以用txt格式表现，也可以用HTML格式、XML格式、JSON格式表现，甚至可以采用二进制格式；图片可以用JPG格式表现，也可以用PNG格式表现。
URI只代表资源的实体，不代表它的形式。严格地说，有些网址最后的".html"后缀名是不必要的，因为这个后缀名表示格式，属于"表现层"范畴，而URI应该只代表"资源"的位置。它的具体表现形式，应该在HTTP请求的头信息中用Accept和Content-Type字段指定，这两个字段才是对"表现层"的描述。
状态转化
访问一个网站，就代表了客户端和服务器的一个互动过程。在这个过程中，势必涉及到数据和状态的变化。
互联网通信协议HTTP协议，是一个无状态协议。这意味着，所有的状态都保存在服务器端。
因此，如果客户端想要操作服务器，必须通过某种手段，让服务器端发生"状态转化"（State Transfer）。而这种转化是建立在表现层之上的，所以就是"表现层状态转化"。
客户端用到的手段，只能是HTTP协议。具体来说，就是HTTP协议里面，四个表示操作方式的动词：GET、POST、PUT、DELETE。它们分别对应四种基本操作：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源。
参考：
