RESTful API接口设计规范

2021-01-02 09:48

阅读:359

标签:app   color   amp   互联网应用   应用程序   数据库   repr   接口设计   方法   

  网络应用程序,分为前端和后端两个部分。当前的发展趋势,就是前端设备层出不穷(手机、平板、桌面电脑、其他专用设备…)。因此,必须有一种统一的机制,方便不同的前端设备与后端进行通信。这导致API构架的流行,甚至出现"API First"的设计思想。RESTful API是目前比较成熟的一套互联网应用程序的API设计理论。

  REST(Representational State Transfer)表述性状态转换,REST指的是一组架构约束条件和原则。 如果一个架构符合REST的约束条件和原则,我们就称它为RESTful架构。REST本身并没有创造新的技术、组件或服务,而隐藏在RESTful背后的理念就是使用Web的现有特征和能力, 更好地使用现有Web标准中的一些准则和约束。虽然REST本身受Web技术的影响很深, 但是理论上REST架构风格并不是绑定在HTTP上,只不过目前HTTP是唯一与REST相关的实例。

一、URI

  URI 表示资源,资源一般对应服务器端领域模型中的实体类。

  一般规范:

1、不用大写;

2、用中杠 - 不用下杠 _;

3、参数列表要encode;

4、URI中的名词表示资源集合,使用复数形式。

5、URI表示资源的两种方式:资源集合、单个资源。

  资源集合:

  /zoos         //所有动物园

  /zoos/1/animals    //id为1的动物园中的所有动物

  单个资源:

  /zoos/1      //id为1的动物园

  /zoos/1;2;3    //id为1,2,3的动物园

6、避免层级过深的Uri

  / 在url中表达层级,用于按实体关联关系进行对象导航,一般根据id导航。

  过深的导航容易导致url膨胀,不易维护,如 GET /zoos/1/areas/3/animals/4,尽量使用查询参数代替路径中的实体导航,如GET /animals?zoo=1&area=3;

7、对组合资源的访问

  服务器端的组合实体必须在uri中通过父实体的id导航访问。

  组合实体不是first-class的实体,它的生命周期完全依赖父实体,无法独立存在,在实现上通常是对数据库表中某些列的抽象,不直接对应表,也无id。一个常见的例子是 User — Address,Address是对User表中zipCode/country/city三个字段的简单抽象,无法独立于User存在。必须通过User索引到Address:GET /user/1/addresses

二、Request

  HTTP方法,通过标准HTTP方法对资源CRUD:

  GET:查询

  POST:创建单个资源。POST一般向“资源集合”型uri发起

  PUT:更新单个资源(全量),客户端提供完整的更新后的资源。与之对应的是 PATCH,PATCH 负责部分更新,客户端提供要更新的那些字段PUT/PATCH一般向“单个资源”型uri发起

  DELETE:删除

  HEAD / OPTION 用的不多,就不多解释了。

1、安全性和幂等性

  1. 安全性:不会改变资源状态,可以理解为只读的;
  2. 幂等性:执行1次和执行N次,对资源状态改变的效果是等价的。

技术图片

   安全性和幂等性均不保证反复请求能拿到相同的response。以 DELETE 为例,第一次DELETE返回200表示删除成功,第二次返回404提示资源不存在,这是允许的。

2、复杂查询

  查询可以捎带以下参数:

. 示例 备注
过滤条件 ?type=1&age=16 允许一定的uri冗余,如/zoos/1/zoos?id=1
排序 ?sort=age,desc  
投影 ?whitelist=id,name,email  
分页 ?limit=10&offset=3  

3、Bookmarker

  经常使用的、复杂的查询标签化,降低维护成本。

GET /trades?status=closed&sort=created,desc

// 快捷方式
GET /trades#recently-closed
或者
GET /trades/recently-closed

4、Format

  只用以下常见的3种body format:

(1)Content-Type: application/json

(2)Content-Type: application/x-www-form-urlencoded (浏览器POST表单用的格式)

  Content-Type: multipart/form-data; boundary=—-RANDOM_jDMUxq4Ot5 (表单有文件上传时的格式)

(3)Content Negotiation

  资源可以有多种表示方式,如json、xml、pdf、excel等等,客户端可以指定自己期望的格式,通常有两种方式:

  http header Accept:Accept:application/xml;q=0.6,application/atom+xml;q=1.0(q为各项格式的偏好程度)

  url中加文件后缀:/zoo/1.json

 

RESTful API接口设计规范

标签:app   color   amp   互联网应用   应用程序   数据库   repr   接口设计   方法   

原文地址:https://www.cnblogs.com/goloving/p/13138628.html


评论


亲,登录后才可以留言!