WebAPI前置知识:HTTP与RestfulAPI

         对HTTP协议的基本了解是能理解并使用RestFul风格API的基础，在了解了这些基础之后，使用各种RestFul的开发框架才能得心应手。我一开始使用WebApi的时候就因为对这些知识缺乏了解，觉得用起来各种不顺手，直到熟悉了这些HTTP的知识后，使用WebApi开发起来才觉得得心应手，我的理解里，RestFul风格的API即是对HTTP协议良好支持，实现HTTP完整语义风格的API。

         在介绍这些知识之前，我需要强调一下很多人存在的一个误区：HTTP的谓词和数据传递方式。绝大多数人接触并使用的HTTP协议都是在网站编写的过程中，在一般的WEB应用中，我们仅使用GET、POST两个谓词，其他谓词并不适用，在这一习惯下很多人有几个奇怪的认知：HTTP协议只适用于网站开发，HTTP仅有两个谓词：GET/POST，HTTP调用数据传递仅使用表单K-V的形式进行；在这种认知下，用这种风格开发的RestApi经常会不伦不类，使用ASP.NET WebAPi也会显得不伦不类，平添麻烦。而我们首先要认识到，网站的数据交互只是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中常用的部分，下面我们来用一张图为大家展示一下这些知识：