Restful API设计规范

RESTFUL是一种网络应用程序的设计风格和开发方式，基于HTTP，可以使用XML格式定义或JSON格式定义。RESTFUL适用于移动互联网厂商作为业务使能接口的场景，实现第三方OTT调用移动网络资源的功能，动作类型为新增、变更、删除所调用资源。

RESTFUL特点包括：

1、每一个URI代表1种资源；

2、客户端使用GET、POST、PUT、DELETE4个表示操作方式的动词对服务端资源进行操作：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源；

3、通过操作资源的表现形式来操作资源；

4、资源的表现形式是XML或者HTML；

5、客户端与服务端之间的交互在请求之间是无状态的，从客户端到服务端的每个请求都必须包含理解请求所必需的信息。

在当前流行的前后端分离架构，人们发现原来这套用于超文本传输的协议是如此适合用于设计基于互联网的api接口，基于http动词以及标准的http status返回信息，能够非常好地描述api的特性，并且可读性非常好。更重要的是，由于http是事实上的互联网通讯标准协议，基于rest设计的api接口，就好像你出国用英语和别人交流，完全不存在沟通障碍。
REST架构，从个人角度理解，核心做了两件事情

资源定位
资源操作

其实从REST的定义中就能看出来，表述层对应的就是描述资源的位置（资源定位），状态转移就是对资源的状态进行变更操作（增删改查）
下面举个实际的例子：
假设我们数据库里有一张User表，我们根据表建好了领域对象模型User，按照restful规范设计的接口应该是这样的：

新增用户

[POST] /users

修改用户

[PUT] /users/{id}

删除用户

[DELETE] /users/{id}

查找全部用户

[GET] /users

从这里也能看出接口命名为对应表名的复数形式，并且[method] 是对应到如下

HTTP Method

rest的定义，第一条叫做资源定位，如果还不理解，那让我们再想想URL的定义，叫做统一资源定位符，也就是说url是用来表示资源在互联网上的位置的，所以说在url中不应该包含动词，只能包含名词。对资源的操作应该体现在http method上面，如果这样理解还比较抽象的话，这里不妨再打一个比方，比如在jane的网站有一张小汽车的图片，地址是http://jane.com/img/car.jpg,现在jane想设计一个api接口，实现对这张图片的删除操作，这个api应该怎么设计？根据rest的设计规范，很容易得出是

[DELETE] http://jane.com/img/car

严格地说，有些网址最后的”.html”后缀名是不必要的，因为这个后缀名表示格式，属于”表现层”范畴，而URI应该只代表”资源”的位置。它的具体表现形式，应该在HTTP请求的头信息中用Accept和Content-Type字段指定，这两个字段才是对”表现层”的描述。

除了HTTP METHOD,rest另外一套重要的规范就是HTTP STATUS，这套状态码规范定义了常规的api操作所可能产生的各种可能结果的描述，遵循这套规范，会使得你的api变得更加可读，同时也便于各种网络、基础设施进行交易状态监控。经常会用到的status code整理如下：

200 OK - [GET]：服务器成功返回用户请求的数据，该操作是幂等的（Idempotent）。
201 CREATED - [POST/PUT/PATCH]：用户新建或修改数据成功。
202 Accepted - [*]：表示一个请求已经进入后台排队（异步任务）
204 NO CONTENT - [DELETE]：用户删除数据成功。
400 INVALID REQUEST - [POST/PUT/PATCH]：用户发出的请求有错误，服务器没有进行新建或修改数据的操作，该操作是幂等的。
401 Unauthorized - [*]：表示用户没有权限（令牌、用户名、密码错误）。
403 Forbidden - [*] 表示用户得到授权（与401错误相对），但是访问是被禁止的。
404 NOT FOUND - [*]：用户发出的请求针对的是不存在的记录，服务器没有进行操作，该操作是幂等的。
406 Not Acceptable - [GET]：用户请求的格式不可得（比如用户请求JSON格式，但是只有XML格式）。
410 Gone -[GET]：用户请求的资源被永久删除，且不会再得到的。
422 Unprocesable entity - [POST/PUT/PATCH] 当创建一个对象时，发生一个验证错误。
500 INTERNAL SERVER ERROR - [*]：服务器发生错误，用户将无法判断发出的请求是否成功。

最后推荐大家github的api文档：

内容出处：，

声明：本网站所收集的部分公开资料来源于互联网，转载的目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。如果您发现网站上有侵犯您的知识产权的作品，请与我们取得联系，我们会及时修改或删除。文章链接：http://www.yixao.com/tech/14549.html

Restful API设计规范

相关推荐

发表评论