NAP6官方旗舰店
搜索
发新帖
午饭无线 推广广告R7800 完胜 华硕路由器NETGEAR Vs ASUS T-Mobile定制版NETGEAR团购
开启左侧

WebAPI前置知识:HTTP与RestfulAPI

[复制链接]
1102 0

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
对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时返回一个网页;当然,将这两种应用方式切割或合并起来都各有优劣。
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

精彩推荐

热点动态

精彩图文

快速回复 返回顶部 返回列表