RESTful API是什么

日期:2018-10-03       浏览:465

一 什么是RESTful

REST全称是Representational State Transfer,中文意思是表述性状态转移。REST本身并没有创造新的技术,它只是一种设计理念,也没有统一的标准,更不是http接口的设计规范,只不过目前http是唯一可以表现REST设计理念的实例。所以接下来我们都是通过http来介绍REST。
通过REST的概念可以get到它表达的有“表述性”,“状态转移”这两层含义。下面我们也主要是对这两层含义的讲解。

二 表述性

2.1 什么是资源

任何事物,只要有被引用到的必要,它就是一个资源。资源可以是实体(例如邮箱),也可以只是一个抽象概念(例如价值) 。下面是一些资源的例子:
  • 某人的手机号
  • 某人的个人信息
  • 文章和类别的关系
  • 某个商品的价格
  • 某人的一个项目
  • 某个项目的所有评论

2.2 什么是URI

URI 的定义是 统一资源标识符(Uniform Resource Identifier)是一个用于标识某一互联网资源名称的字符串。
定义已经告诉了我们,URI 是用来唯一标识互联网上的资源访问路径的。也就是说互联网上的所有资源都可以通过一个 URI 定位到。我们最常用的web网络资源的表示形式可以通过下图说明:
URI 表示的资源层次图
URI 表示的资源层次图
  1. IP:一个IP地址唯一标识了一台主机;
  2. port:一台主机可以有多个对外开放的端口,指定某个端口可以找到这个端口对外提供的服务;
  3. app:一个端口下可以发布多个应用,就像一个tomcat下可以部署多个项目。通过项目名称可以找到对应的项目;
  4. path:一个项目下会存在多个拦截请求的路径,通过路径名称可以唯一确定http请求操作的资源;
由上图可以看出 web 资源的访问路径是有层次关系的。

2.3 URI案例分析

以上我们已经介绍了 URI 的概念及其作用,接下来我们以世界上最大的同性交友网站Github的其中一个查看评论的URL为例,看一看他们是怎么定义的。如下图:
rest url 描述
rest url 描述
我们可以看到 Github 定义的 URL 和 URI 的定义描述非常贴切,我们通过 URI 就可以唯一确定我们要操作的资源。
统一的资源接口要求使用标准的 HTTP 方法对资源进行操作,所以 URI 只应该来表述资源的名称,而不应该包涵对资源的操作。概括的说就是 URI 不应该包涵动作相关的描述。
总结:网络资源的访问路径具有层次性,在对 URI 的设计和定义时,也应该考虑对访问资源的层次和表述性。

三 状态转移

3.1 资源有哪些操作

上面介绍了什么是资源,怎么表述一个资源。那针对表述的资源又存在哪些操作呢?
针对资源的操作可以概括为增删改查,更复杂一点的无非就是把增删改查排列组合一下。
在 HTTP 协议中怎么将增删改查表示出来呢?其实 HTTP 协议在定义的时候就已经考虑到了这些,所以定义了相对应的Request Method,如下表所示:
操作 Request Method
新建资源 POST
删除资源 DELETE
更新资源 PUT
查找资源 GET
针对资源的操作结果就是改变了资源的某些状态信息。GET 请求可以认为说改变了资源的浏览量。
虽然我们上面列出来了这些方法,但是很多浏览器并不是全部支持,旧版本的浏览器只能支持GET和POST两种方法。在真实的实践中,服务端和客户端都需要做一些妥协,例如可以通过在请求体 Request Body 中增加请求参数 _method = DELETE 来指定对资源的操作。

3.2 Request Headers

以上介绍了对资源的操作方法,但是在具体实践过程中还需要资源相关的更多元数据或请求信息。在 HTTP 协议中 Request Headers 就是可以添加这些信息的一个地方,下面我们看一下常见的 Request Headers 具体是什么样的。
Accept:text/plain, text/html
Accept-Language:zh-CN,zh;q=0.8,en;q=0.6
Connection:keep-alive
Host:localhost
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6)
Content-Length:27
Content-Type:application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
各字段代表的含义:
Request Headers 描述
Accept 本次请求可接收的返回内容类型
Accept-Language 可接收的语言
Connection 是否需要保持本次链接
Host 请求的远程主机名
User-Agent 本地代理信息
Content-Length 请求的内容数据长度
Content-Type 请求的内容数据类型
Accept-Encoding 可接收响应内容编码方式
Request Headers 只是协议中定义好的业务无关的信息,在实践中更多的是一些业务相关的信息,这时就需要用到 Request Body,Request Body 是用户自定义的一些请求信息,其具体的数据类型是 Request Headers 的 Content-Type 中已经定义好的。

3.3 Status Code

上面介绍了这么多 HTTP 请求相关的信息,在一次 HTTP 连接中有请求必定是要有响应的。下面就简单的说一下一些常见的响应码 Status Code 都有哪些及其具体含义:
Status Code 描述
200 成功
301 永久重定向
302 暂时重定向
400 坏请求(如:参数错误)
404 资源不存在(请求地址不存在)
406 请求方法错误
500 服务器内部异常
503 服务器当前太繁忙,无法处理请求
总结:Restful API的设计,不仅仅包涵 URI 的标准定义,还需要借助 HTTP 协议相关信息的配合。

四 案例分析

所有系统都会涉及到用户相关数据,也就会存在一个共有的资源--用户。下面我们就以针对用户相关操作的接口为例,讨论一下具体的设计。
大部分系统都是分布式的,分布式系统为了做到授权都会选择分布式 session(俗称 token),但是要做到 token 的安全又会统一使用 post 请求。
下面是一些常见的不符合 Restful 的设计:
操作 请求方法 请求路径 请求数据
添加用户 post /v1.0/createUser {"name": "aa","token": "123"}
更新用户 post /v1.0/updateUser {"id":1,"name": "bb","token": "123"}
获取用户 post /v1.0/getUser {"id": 1,"token": "123"}
删除用户 post /v1.0/deleteUser {"id": 1,"token": "123"}
以上的接口设计将对资源的操作动作写在了 URI 的请求路径信息里,并且从路径信息无法唯一定位到某个具体的资源,对同一个资源又存在多个路径访问,且请求方法统一使用 post(这个为了 token 的安全是没问题的)。
下面我们再看一下一个更符合 Restful 设计规范的接口定义是什么样子的:
操作 请求方法 请求路径 请求数据
添加用户 post /v1.0/user {"_methd": "post","name": "aa","token": "123"}
更新用户 post /v1.0/user/:id {"_methd":"put","name": "bb","token": "123"}
获取用户 post /v1.0/user/:id {"_methd": "get","token": "123"}
删除用户 post /v1.0/user/:id {"_methd": "delete","token": "123"}
扫码关注有惊喜

(转载本站文章请注明作者和出处 qbian)

暂无评论

Copyright 2016 qbian. All Rights Reserved.

文章目录