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中经常使用的部分，下面咱们来用一张图为你们展现一下这些知识：