2020年5月15日星期五

RESTful设计中的常见疑问

RESTful设计中的常见疑问


最近写了几个有关RESTful的API相关内容,也谈谈对常见问题的自己的理解。

1.什么是RESTful

详情可以 VERB(GET PUT等)对资源的操作。

2.为什么要用RESTful

使用RESTful,优点有很多,也方便不同的请求方去请求数据。列举两个:

  • HTTP方法语义都很明确,使用GET去获得数据,使用DELETE去删除数据。
  • 返回值也是很明确的HTTP RESPONSE,200就是执行成功,400就是请求错误。

那是不是每一个API都需要使用REST风格呢?我觉得不是,这要看团队、项目而定,不必一味强求。

3.在URI资源地址中使用v1之类的版本号符不符合RESTful?

这个涉及到RESTful的版本管理,常见的方法有这么几种。

URL Path

/api/v1/helloworld

很多公开的API地址里面,都带有version信息,如果非要去扣符不符合RESTful,估计要吵起来。但是这个方式很便捷、明确,调用方一看就明白,也没有额外的工作量去做。不过缺点也很明显,由于已经限定死了版本号在URI中,无法实现同一个URI地址版本的灵活切换,也不能指定默认版本。

Query String

/api/helloworld?api-version=1.0

这个方式没有改变URI本身,但是需要调用方去额外处理Query string,不过好在这个可以指定默认的。

Media Types

POST api/helloworld HTTP/1.1host: localhostcontent-type: text/plain;v=2.0content-length: 12Hello there!

在Content-Type里面添加v=x.x的版本号也是一个不错的选择,可以实现QueryString类似的功能。

有一些现成的库可以帮助我们实现上面的Versioning方法,常见的是aspnet-api-versioning

4.什么是安全性?

无论请求多少次,服务器的状态(资源)都不会改变,那么这个方法就是安全的。

GET HEAD都应该设计成安全的。

5.什么是幂等性?

无论对资源操作多少次,服务器资源结果总是一样的,那么这个方法就是幂等的。注意这里的说法,是服务器的资源结果是一样的,不代表请求的返回结果是一样的。比如DELETE请求,它是幂等的,但是删除一个资源很多次的情况(多次执行DELETE api/student/1,第一次返回成功,第二次返回失败,但是不影响服务器上对应的记录已经删除的状态。

GET、HEAD、PUT和DELETE请求都应该设计成是幂等的。

6.新增数据用POST还是PUT?

资源新增可以用POST也可以用PUT,但是设计上有几个区别。

幂等性

PUT是幂等的,POST不是,如果设计上需要不应用幂等性,那么使用POST。比如POST计数器的应用,每次POST,计数器都增长1。

请求目标

POST一般请求的是资源集合,而PUT一般请求是一个具体的资源。

PUT /students/{id}POST /students

这也意味着,语义上,POST是请求在集合中新增资源。

主动权

  • 如果id不是由调用方生成的情况下,需要指定的资源ID的PUT方法就不好实现了。这种情况,使用POST到资源更合理,主动权在服务器方,服务器创建资源之后,返回201携带新生成的对象URI。
  • 如果id是由调用方生成的情况下(比如一些硬件设备产生的数据),使用POST和PUT都可以,但是PUT有幂等性,显得更加明确,这种时候我一般选择使用PUT。

覆盖

PUT语义是要求覆盖的,如果数据已经存在,就必须覆盖。POST的没有这个要求,可以有别的行为。

7.修改数据应该使用PUT还是PATCH?

不一定,要看情况。PUT是覆盖性的修改,而PATCH是追加性的修改。

  • 使用PUT的时候,需要将数据完整返回,如果有的字段没有赋值,那么将保持为默认值。
  • PUT是幂等的,PATCH不是,因此多次执行PUT请求,结果是一样的;执行PATCH有可能不一样。
{"value":  {  "id": "235314",  "deviceId": "123",  "type": "低温" }}

如果发送的数据只含有deviceId,执行PUT之后,资源变成:

{"value":  {  "id": "235314",  "deviceId": "111" }}

执行PATCH,资源变成:

{"value":  {  "id": "235314",  "deviceId": "111",  "type": "低温" }}

8.没有数据返回204还是404?

问题:

如果请求一个这样的资源

GET api/sutudents/homework

在没有homework的情况下应该返回HTTP 204 NoContent还是返回HTTP 404 NotFound?

乍看一眼,觉得好像都差不多,没内容和没找到反正都是没有。但深入想想,还是有很大的区别的。

  1. 404返回的更倾向于表述不存在的性质,而204返回表述没有内容,也就是存在,但是没有内容。
  2. 4xx返回表述大体是请求有问题,而2xx返回表述大体是请求没有问题。

所以,对于上面的问题,这么理解,如果homework是已经创建的资源,但是内容为空,那么返回204是可以的,但是如果homework这个东西就不存在,那么应该返回404。

个人认为直接返回200,携带对应的空内容会比204要对调用方更加友好,至少和有数据的情况是一样处理。

9.写给前端

有很多前端同学需要服务器返回固定的成功信息(比如200)或者错误信息(比如400)。但HTTP CODE很多,一个一个判断效率很低,好在HTTP CODE是分类的,比如2xx大体是OK的,4xx都是有问题的。可以通过CODE / 100 == 2之类的方法去大体确定返回的状态 。


没有评论:

发表评论