为什么少有人使用RESTful API?

·  阅读 45358
为什么少有人使用RESTful API?

前言

新文章:如何设计出一个优秀的API 在上年写了一篇《后端API接口的错误信息返回规范》,这是符合RESTful规范(严谨一点是类RESTful)的错误信息。掘友们却对这种规范存在不同意见,都倾向于只要是后端可以正确收到请求,那都是200。异常都交给业务处理。

而且不仅是错误信息返回规范,API设计都很少遵循RESTful风格,大多数都是类JSON RPC。这是为什么呢?

RESTful API

想要回答这个问题,首先得知道RESTful风格的API是什么样的。

其实关于RESTful的基本概念,我在上篇文章《方法论:如何学习HTTP》也介绍过了,在这就不再赘述了。

接下来看看一个完整的RESTful API是怎么形成的。

Richardson Maturity Model

Leonard Richardson提出了一种以他命名的模型Richardson Maturity Model,循序渐进的介绍了迈向RESTful的不同等级。 image.png

但需要强调的是,RMM虽然是思考RSET的一个好方法,但它不是REST的定义。RMM有用的地方只是在于它提供了一个很好的step by step的方法来理解REST思想背后的基本理念。

Level 0

这是最基本的等级,在这等级中只是简单的使用HTTP作为远程交互的传输隧道,而不是当成传输协议来使用,不涉及任何web的机制。举个例子:

我今天约了小伙伴打羽毛球,于是发起一个请求向体育馆询问哪个时间段可以预定羽毛球场。

POST /stadiumReception HTTP/1.1
[various other headers]

{
    "date": "2022-01-05",
    "sport": "badminton"
}
复制代码

前台返回今天羽毛球场可以预定的时间段

HTTP/1.1 200 OK
[various headers]

{
    "times": [
        {
            "start": "1400",
            "end": "1600"
        },
        {
            "start": "1700",
            "end": "1830"
        }
    ]
}
复制代码

得到时间段信息,再约一下时间,决定预定17点到18点半,打完吃饭。

POST /stadiumReception HTTP/1.1
[various other headers]

{
    "date": "2022-01-05",
    "sport": "badminton",
    "start": "1700",
    "end": "1830"
}
复制代码

预定成功!

HTTP/1.1 200 OK
[various headers]

{
    "orderId": "123456789"
}
复制代码

可以看到这是非常典型的JSON RPC格式,当然在实际开发中API设计要比这好很多。

Level1:面向资源

在RMM模型(Richardson Maturity Model)中迈向REST顶点的第一步就是面向资源,所以把独立资源替代单一的接口节点。

因此,可能会将不同运动,比如羽毛球等抽象为独立的资源。所以请求修改为如下:

POST /sports/badminton HTTP/1.1
[various other headers]

{
    "date": "2022-01-05"
}
复制代码

询问某个日期,羽毛球场的可预定时间。

HTTP/1.1 200 OK
[various headers]

{
    "times": [
        {
            "start": "1400",
            "end": "1600",
            "id": "123456789"
        },
        {
            "start": "1700",
            "end": "1830",
            "id": "987654321"
        }
    ]
}
复制代码

返回比原有基础上增加了单独的id,可以表示羽毛球场的特定空闲时间段。

这时就能选定某个时间段,将其id向预约接口预定。

POST /reservations/987654321 HTTP/1.1
[various other headers]
复制代码

预定成功!

HTTP/1.1 200 OK
[various headers]

{
    "orderId": "abcd987654321"
}
复制代码

可以看到与level0最大的不同就是对单一的节点做操作,变成了对不同的资源做操作。

Level2:HTTP动词

Level2,真正将HTTP作为了一种传输协议,最直观的一点就是Level2使用了HTTP动词,GET/PUT/POST/DELETE/PATCH等,这些都是HTTP的规范,规范的作用自然是重大的,用户看到一个POST请求,就知道它不是幂等的,使用时要小心。而看到GET,就知道它是幂等的,调用多几次都不会造成问题,当然,这些的前提都是API的设计者和开发者也遵循这一套规范。

所以对于询问某个日期,羽毛球场的可预定时间,可改为

GET /sports/badminton/20220105?status=idle HTTP/1.1
[various other headers]
复制代码

HTTP将GET定义为安全操作,这意味着它不会对任何状态进行更改。所以我们可以任意多次调用GET,并每次都能得到相同的结果。而且web还会缓存GET请求与结果,这是Web架构工作良好的关键因素。

返回结果一样的,接着我们预定一个时间段。

POST /reservations/987654321 HTTP/1.1
[various other headers]
复制代码

请求不变,但返回却改变了。如果一切顺利,服务将返回一个201响应码,表示有一个新资源产生了。

HTTP/1.1 201 Created
Location: orders/abcd987654321
[various headers]

{
    "orderId": "abcd987654321"
}
复制代码

201响应还包括了Location属性,指明客户端可以使用该属性的URL来获取该订单资源的最新状态。

如果出现错误,例如其他人预订了该时段,则:

HTTP/1.1 409 Conflict
[various headers]

{
    "error": "该时间段已被预定"
}
复制代码

此响应的重要部分是使用正确的HTTP响应码来表示出错的地方。在该场景中,409是一个很好的选择,表明其他人已经以互斥的方式更新了资源。 在Level 2,我们明确使用某种类型的错误响应,而不是使用返回码200但包含错误响应。

Level3:HATEOAS

HATEOAS(Hypertext As The Engine Of Application State),中文翻译为“将超媒体当作应用状态引擎”,这个描述的核心是超媒体概念,换句话说:是链接的思想。

从Level2的请求开始:

GET /sports/badminton/20220105?status=idle HTTP/1.1
[various other headers]
复制代码

返回的信息是与Level2不同的

HTTP/1.1 200 OK
[various headers]

{
    "times": [
        {
            "start": "1400",
            "end": "1600",
            "id": "123456789",
            "link": "/reservations/123456789"
        },
        {
            "start": "1700",
            "end": "1830",
            "id": "987654321",
            "link": "/reservations/987654321"
        }
    ]
}
复制代码

每个时间段现在都有一个link元素,其中包含一个URI,告诉我们如何预约。超媒体控制的要点是,告诉我们下一步可以做什么,以及我们需要操作的资源URI。我们不必知道预约的请求发到哪里去,响应中的超媒体控制会告诉我们怎么去做。

预约请求仍用回level2的

POST /reservations/987654321 HTTP/1.1
[various other headers]
复制代码

回复中包含了许多超媒体控制,用于下一步要做的不同事情。

HTTP/1.1 201 Created
Location: orders/abcd987654321
[various headers]

{
    "orderId": "abcd987654321",
    "link": {
        "rel": "delete",
        "uri": "/orders/abcd987654321"
    }
}
复制代码

返回提供了如何取消该订单。

Level3的Restful API,给使用者带来了很大的便利,使用者只需要知道如何获取资源的入口,之后的每个URI都可以通过请求获得,无法获得就说明无法执行那个请求。

RESTful的缺点

需要强调的一点是,RESTful不是一种规范,而是一种风格,它是不具有强制性的。所以风格这种东西说不准,公说公有理,婆说婆有理。就算是相同水平的程序员设计的“RESTful”也很难一样。而在开发团队中,最忌讳的就是不统一!

1、RESTful是面向资源的,所以接口都是一些名词,尤指复数名词。简单的CRUD还是很合适的,但很多业务逻辑都很难将其抽象为资源。比如说登录/登出,怎么看也不是一个资源,如果硬是抽象为创建一个session/删除一个session。这不仅反直觉,还违背了RESTful的思想。

2、RESTful只提供了基本的增删改查,对于复杂的逻辑是一点办法没有,比如批量下载、批量删除等。对于复杂的查询,更是无从下手。而且开发时会面临诸多选择,修改资源用PUT还是PETCH?采用查询参数还是用body?

3、关于错误码的问题更是复杂的一批,RESTful建议使用status code作为错误码,以便统一。在实际开发中,业务逻辑的含义数不胜数,很难统一。比如400状态码到底是表示传参有问题,还是该资源已被占用了。404是表示接口不存在,还是资源不存在。

发展到最后,开发人员的时间精力都不是用于怎么实现这个逻辑,而是变成了纠结这逻辑到底是个什么资源?把时间都给浪费掉,最后还给出了一个不伦不类的“RESTful”API。

最重要一点是RESTful与RPC没有高低之分,所有的代码规范、接口设计以及各种规定,其实都是为了在团队内部形成共识、防止个人习惯差异引起的混乱。相比之下形成JSON-RPC规范相对容易以及更方便使用。

就算团队里面规定必须用动作表示URL,所有请求都要使用POST,这也是没问题的。

所以无论是RESTful还是RPC,归根到底还是为了开发人员和产品应用服务的,如果它能带来便利、减少混乱,就值得用;反之,如果带来的麻烦比要解决的还多,那就duck不必了。

结尾

前两年由于经验不足,给了一些自以为正确的意见,现在想想还真是太年轻了🤭,有句话说的对:学的越多感觉自己越无知。

创作不易,烦请动动手指点一点赞。

更多文章请移步楼主github,如果喜欢请点一下star,对作者也是一种鼓励。

分类:
后端
标签:
收藏成功!
已添加到「」, 点击更改