|
|
51CTO旗下网站
|
|
移动端

避免自己写的 Url 被diss!建议看看这篇RestFul API简明教程!

RestFul API 是每个程序员都应该了解并掌握的基本知识,我们在开发过程中设计 API 的时候也应该至少要满足 RestFul API 的最基本的要求(比如接口中尽量使用名词,使用 POST 请求创建资源,DELETE 请求删除资源等等,示例:GET /notes/id:获取某个指定 id 的笔记的信息)。

作者:JavaGuide来源:Guide哥|2020-03-25 11:04

 

RestFul API 是每个程序员都应该了解并掌握的基本知识,我们在开发过程中设计 API 的时候也应该至少要满足 RestFul API 的最基本的要求(比如接口中尽量使用名词,使用 POST 请求创建资源,DELETE 请求删除资源等等,示例:GET /notes/id:获取某个指定 id 的笔记的信息)。

如果你看 RestFul API 相关的文章的话一般都比较晦涩难懂,包括我下面的文章也会提到一些概念性的东西。但是,实际上我们平时开发用到的 RestFul API 的知识非常简单也很容易概括!举个例子,如果我给你下面两个 url 你是不是立马能知道它们是干什么的!这就是 RestFul API 的强大之处!

RestFul API 可以你看到 url + http method 就知道这个 url 是干什么的,让你看到了 http 状态码(status code)就知道请求结果如何。

  1. GET    /classs:列出所有班级 
  2. POST   /classs:新建一个班级 

下面的内容只是介绍了我觉得关于 RestFul API 比较重要的一些东西,欢迎补充。

一、重要概念

REST,即 REpresentational State Transfer 的缩写。这个词组的翻译过来就是"表现层状态转化"。这样理解起来甚是晦涩,实际上 REST 的全称是 Resource Representational State Transfe ,直白地翻译过来就是 “资源”在网络传输中以某种“表现形式”进行“状态转移” 。如果还是不能继续理解,请继续往下看,相信下面的讲解一定能让你理解到底啥是 REST 。

我们分别对上面涉及到的概念进行解读,以便加深理解,不过实际上你不需要搞懂下面这些概念,也能看懂我下一部分要介绍到的内容。不过,为了更好地能跟别人扯扯 “RestFul API”我建议你还是要好好理解一下!

  • 资源(Resource) :我们可以把真实的对象数据称为资源。一个资源既可以是一个集合,也可以是单个个体。比如我们的班级 classs 是代表一个集合形式的资源,而特定的 class 代表单个个体资源。每一种资源都有特定的 URI(统一资源定位符)与之对应,如果我们需要获取这个资源,访问这个 URI 就可以了,比如获取特定的班级:/class/12。另外,资源也可以包含子资源,比如 /classs/classId/teachers:列出某个指定班级的所有老师的信息
  • 表现形式(Representational):"资源"是一种信息实体,它可以有多种外在表现形式。我们把"资源"具体呈现出来的形式比如 json,xml,image,txt 等等叫做它的"表现层/表现形式"。
  • 状态转移(State Transfer) :大家第一眼看到这个词语一定会很懵逼?内心 BB:这尼玛是啥啊?大白话来说 REST 中的状态转移更多地描述的服务器端资源的状态,比如你通过增删改查(通过 HTTP 动词实现)引起资源状态的改变。ps:互联网通信协议 HTTP 协议,是一个无状态协议,所有的资源状态都保存在服务器端。

综合上面的解释,我们总结一下什么是 RESTful 架构:

  1. 每一个 URI 代表一种资源;
  2. 客户端和服务器之间,传递这种资源的某种表现形式比如 json,xml,image,txt 等等;
  3. 客户端通过特定的 HTTP 动词,对服务器端资源进行操作,实现"表现层状态转化"。

二、REST 接口规范

1、动作

  • GET :请求从服务器获取特定资源。举个例子:GET /classs(获取所有班级)
  • POST :在服务器上创建一个新的资源。举个例子:POST /classs(创建班级)
  • PUT :更新服务器上的资源(客户端提供更新后的整个资源)。举个例子:PUT /classs/12(更新编号为 12 的班级)
  • DELETE :从服务器删除特定的资源。举个例子:DELETE /classs/12(删除编号为 12 的班级)
  • PATCH :更新服务器上的资源(客户端提供更改的属性,可以看做作是部分更新),使用的比较少,这里就不举例子了。

2、路径(接口命名)

路径又称"终点"(endpoint),表示 API 的具体网址。实际开发中常见的规范如下:

  • 网址中不能有动词,只能有名词,API 中的名词也应该使用复数。 因为 REST 中的资源往往和数据库中的表对应,而数据库中的表都是同种记录的"集合"(collection)。如果 API 调用并不涉及资源(如计算,翻译等操作)的话,可以用动词。 比如:GET /calculate?param1=11¶m2=33
  • 不用大写字母,建议不用中杠 - 不用下杠 _ 比如邀请码写成 invitation-code而不是invitation_code

Talk is cheap!来举个实际的例子来说明一下吧!现在有这样一个 API 提供班级(class)的信息,还包括班级中的学生和教师的信息,则它的路径应该设计成下面这样。

接口尽量使用名词,禁止使用动词。 下面是一些例子:

  1. GET    /classs:列出所有班级 
  2. POST   /classs:新建一个班级 
  3. GET    /classs/classId:获取某个指定班级的信息 
  4. PUT    /classs/classId:更新某个指定班级的信息(一般倾向整体更新) 
  5. PATCH  /classs/classId:更新某个指定班级的信息(一般倾向部分更新) 
  6. DELETE /classs/classId:删除某个班级 
  7. GET    /classs/classId/teachers:列出某个指定班级的所有老师的信息 
  8. GET    /classs/classId/students:列出某个指定班级的所有学生的信息 
  9. DELETE classs/classId/teachers/ID:删除某个指定班级下的指定的老师的信息 

反例:

  1. /getAllclasss 
  2. /createNewclass 
  3. /deleteAllActiveclasss 

理清资源的层次结构,比如业务针对的范围是学校,那么学校会是一级资源:/schools,老师: /schools/teachers,学生: /schools/students 就是二级资源。

3、过滤信息(Filtering)

如果我们在查询的时候需要添加特定条件的话,建议使用 url 参数的形式。比如我们要查询 state 状态为 active 并且 name 为 guidegege 的班级:

  1. GET    /classs?state=active&name=guidegege 

比如我们要实现分页查询:

  1. GET    /classs?page=1&size=10 //指定第1页,每页10个数据 

4、状态码(Status Codes)

三、HATEOAS

RestFul 的极致是 hateoas ,但是这个基本不会在实际项目中用到。

上面是 RESTful API 最基本的东西,也是我们平时开发过程中最容易实践到的。实际上,RESTful API 最好做到 Hypermedia,即返回结果中提供链接,连向其他 API 方法,使得用户不查文档,也知道下一步应该做什么。

比如,当用户向 api.example.com 的根目录发出请求,会得到这样一个文档。

  1. {"link": { 
  2.   "rel":   "collection https://www.example.com/classs"
  3.   "href":  "https://api.example.com/classs"
  4.   "title""List of classs"
  5.   "type":  "application/vnd.yourformat+json" 
  6. }} 

上面代码表示,文档中有一个 link 属性,用户读取这个属性就知道下一步该调用什么 API 了。rel 表示这个 API 与当前网址的关系(collection 关系,并给出该 collection 的网址),href 表示 API 的路径,title 表示 API 的标题,type 表示返回类型 Hypermedia API 的设计被称为HATEOAS。

在 Spring 中有一个叫做 HATEOAS 的 API 库,通过它我们可以更轻松的创建除符合 HATEOAS 设计的 API。

【编辑推荐】

  1. IT 行业薪水:系统和数据架构师、云工程师薪资最高;增长最快的技术 K8s
  2. 2020年的13个优秀企业架构工具
  3. 什么是真正的架构设计?十年Java经验让我总结出了这些,不愧是我
  4. 高性能前端架构解决方案
  5. 微服务中,如何交付一款成功的API
【责任编辑:武晓燕 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

订阅专栏+更多

 敏捷无敌之 Gitlab CI 持续集成

敏捷无敌之 Gitlab CI 持续集成

打破运维与研发壁垒
共5章 | KaliArch

91人订阅学习

秒杀高并发白话实战

秒杀高并发白话实战

主流高并发架构
共15章 | 51CTO崔皓

59人订阅学习

网络排障一点通

网络排障一点通

网络排障及优化调整案例
共20章 | 捷哥CCIE

465人订阅学习

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊

51CTO服务号

51CTO官微