Skip to main content

RESTful API Design

什么是 API?

API(Application Programming Interface) 翻译过来是应用程序编程接口的意思。

我们在进行后端开发的时候,主要的工作就是为前端或者其他后端服务提供 API 比如查询用户数据的 API 。

但是, API 不仅仅代表后端系统暴露的接口,像框架中提供的方法也属于 API 的范畴。

为了方便大家理解,我再列举几个例子:

  1. 你通过某电商网站搜索某某商品,电商网站的前端就调用了后端提供了搜索商品相关的 API。
  2. 你使用 JDK 开发 Java 程序,想要读取用户的输入的话,你就需要使用 JDK 提供的 IO 相关的 API。
  3. ......

你可以把 API 理解为程序与程序之间通信的桥梁,其本质就是一个函数而已。另外,API 的使用也不是没有章法的,它的规则由(比如数据输入和输出的格式)API 提供方制定。

何为 RESTful API?

RESTful API 经常也被叫做 REST API,它是基于 REST 构建的 API。例如:

GET    /classes:列出所有班级
POST /classes:新建一个班级

RESTful API 可以让你看到 URL+Http Method 就知道这个 URL 是干什么的,让你看到了 HTTP 状态码(status code)就知道请求结果如何。

像咱们在开发过程中设计 API 的时候也应该至少要满足 RESTful API 的最基本的要求(比如接口中尽量使用名词,使用 POST 请求创建资源,DELETE 请求删除资源等等,示例:GET /notes/id:获取某个指定 id 的笔记的信息)。

解读 REST

RESTREpresentational State Transfer 的缩写。这个词组的翻译过来就是“表现层状态转化”。

REST 的全称是 Resource Representational State Transfer ,直接理解是 “资源”在网络传输中以某种“表现形式”进行“状态转移”.

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

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

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

RESTful API 规范

动作

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

路径(接口命名)

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

  1. 网址中不能有动词,只能有名词,API 中的名词也应该使用复数。 因为 REST 中的资源往往和数据库中的表对应,而数据库中的表都是同种记录的"集合"(collection)。如果 API 调用并不涉及资源(如计算,翻译等操作)的话,可以用动词。比如:GET /calculate?param1=11&param2=33
  2. 不用大写字母,建议用中杠 - 不用下杠 _ 。比如邀请码写成 invitation-code而不是 invitation_code
  3. 善用版本化 API。当我们的 API 发生了重大改变而不兼容前期版本的时候,我们可以通过 URL 来实现版本化,比如 http://api.example.com/v1http://apiv1.example.com 。版本不必非要是数字,只是数字用的最多,日期、季节都可以作为版本标识符,项目团队达成共识就可。
  4. 接口尽量使用名词,避免使用动词。 RESTful API 操作(HTTP Method)的是资源(名词)而不是动作(动词)。

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

GET    /classes:列出所有班级
POST /classes:新建一个班级
GET /classes/{classId}:获取某个指定班级的信息
PUT /classes/{classId}:更新某个指定班级的信息(一般倾向整体更新)
PATCH /classes/{classId}:更新某个指定班级的信息(一般倾向部分更新)
DELETE /classes/{classId}:删除某个班级
GET /classes/{classId}/teachers:列出某个指定班级的所有老师的信息
GET /classes/{classId}/students:列出某个指定班级的所有学生的信息
DELETE /classes/{classId}/teachers/{ID}:删除某个指定班级下的指定的老师的信息

反例:

/getAllclasses
/createNewclass
/deleteAllActiveclasses

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

过滤信息(Filtering)

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

GET    /classes?state=active&name=guidegege

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

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

状态码(Status Codes)

状态码范围:

2xx:成功3xx:重定向4xx:客户端错误5xx:服务器错误
200 成功301 永久重定向400 错误请求500 服务器错误
201 创建304 资源未修改401 未授权502 网关错误
403 禁止访问504 网关超时
404 未找到
405 请求方法不对

学习示例

  • 5 GET APIs with different response type
  • 5 Post API with json request body, please also paste the response here
  • 3 PUT API with json request body, please also paste the response here
  • 2 DELETE API
  • Each example with 404, 401,500 and any http status codes you know

GET

  • 200 OK: GET https://ghibliapi.herokuapp.com/species
  • 404 Not Found: GET https://ghibliapi.herokuapp.com/species/100
  • 200 OK: GET https://reqres.in/api/users?page=2
  • 404 Not Found: GET https://reqres.in/api/users/23
  • 400 Bad Request

POST

  • 201 Created: POST https://reqres.in/api/users
// request body
{
"name": "morpheus",
"job": "leader"
}

// response
{
"name": "morpheus",
"job": "leader",
"id": "984",
"createdAt": "2022-06-17T23:33:51.024Z"
}
  • 200 OK: POST https://reqres.in/api/register
// request body
{
"email": "eve.holt@reqres.in",
"password": "pistol"
}

// response
{
"id": 4,
"token": "QpwL5tke4Pnpja7X4"
}
  • 400 Bad Request: POST https://reqres.in/api/register
// request body
{
"email": "sydney@fife"
}

// response
{
"error": "Missing password"
}
  • 200 OK: POST https://reqres.in/api/login
// request body
{
"email": "eve.holt@reqres.in",
"password": "cityslicka"
}

// response
{
"token": "QpwL5tke4Pnpja7X4"
}
  • 400 Bad Request: POST https://reqres.in/api/login
// request body
{
"email": "peter@klaven"
}

// response
{
"error": "Missing password"
}

PUT

  • 200 OK : PUT https://reqres.in/api/users/2
// request body
{
"name": "morpheus",
"job": "zion resident"
}

// response
{
"name": "morpheus",
"job": "zion resident",
"updatedAt": "2022-06-17T23:44:31.189Z"
}
  • 404 Not Found: PUT https://api.getpostman.com/scim/v2/Users
// request body
null

// response
{
"error": {
"name": "NotFound",
"message": "We can't seem to find what you are looking for."
},
"status": "error"
}

DELETE

  • 204 No Content: DELETE https://reqres.in/api/users/2
// response
null

Best Practice Examples

1. Find 2 collection of APIs example. ie. Twitter, Paypal, Youtube etc. -- 命名规范

  • Twitter: Reference
    • Followers of user ID: GET https://api.twitter.com/2/users/:id/followers
    • Users a user ID is following: GET https://api.twitter.com/2/users/:id/following
    • Recent search: GET https://api.twitter.com/2/tweets/search/recent?query=
    • List Tweets lookup: GET https://api.twitter.com/2/lists/:id/tweets
    • Single Tweet lookup: GET https://api.twitter.com/2/tweets/:id
    • Mute a user ID: POST https://api.twitter.com/2/users/:id/muting
    • Unmute a user ID: DELETE https://api.twitter.com/2/users/:source_user_id/muting/:target_user_id
    • Like a Tweet: POST https://api.twitter.com/2/users/:id/likes
    • Unlike a TWeet: DELETE https://api.twitter.com/2/users/:id/likes/:tweet_id
  • PayPal: Reference
    • User Info: GET {{base_url}}/v1/identity/oauth2/userinfo?schema=paypalv1.1
    • Create order: POST {{base_url}}/v2/checkout/orders
    • Show order details: GET {{base_url}}/v2/checkout/orders/:order_id
    • List transactions: GET {{base_url}}/v1/reporting/transactions?fields=transaction_info,payer_info,shipping_info,auction_info,cart_info,incentive_info,store_info&start_date=2022-02-20T23:59:59.999Z&end_date=2022-03-20T00:00:00.000Z
    • Fully update invoice: PUT {{base_url}}/v2/invoicing/invoices/:invoice_id?send_to_recipient=true&send_to_invoicer=true
    • Show tracking information: GET {{base_url}}/v1/shipping/trackers/:tracking_id

2. Design a collection of APIS for a Blog Website, please specify GET POST PUT DELETE

  • Retrieving posts from a blog: GET https://www.googleapis.com/blogger/v3/blogs/blogId/posts
  • Retrieving a specific post: GET https://www.googleapis.com/blogger/v3/blogs/blogId/posts/postId
  • Adding a post: POST https://www.googleapis.com/blogger/v3/blogs/blogId/posts/
  • Deleting a post: DELETE https://www.googleapis.com/blogger/v3/blogs/blogId/posts/postId
  • Updating a post: PUT https://www.googleapis.com/blogger/v3/blogs/blogId/posts/postId

常见问答

1. In REST, when do we use pathvariable? when we use request paramter?

  • To identify a resource, we can use pathvariable.
  • But if you want to sort or filter items, then you should use request parameter.

2. Difference between SOAP and REST

  • SOAP (Simple Object Access Protocol)
    • SOAP is a protocol, it follows a strict standard to allow communication between the client and the server.
    • SOAP is difficult to implement and it requires more bandwidth.
    • Benefits of SOAP over REST as SOAP has ACID compliance transaction. Some of the applications require transaction ability.
    • SOAP cannot make use of REST since SOAP is a protocol without any architectural pattern.
  • REST (REpresentational State Transfer)
    • REST is an architectural style that doesn’t follow any strict standard.
    • REST is easy to implement and requires less bandwidth such as smartphones.
    • REST lacks ACID compliance transaction.
    • REST can make use of SOAP because it is an architectural pattern having protocol.

参考