什么是RESTful

简介: RESTful是一种面向资源的API设计规范,通过统一接口操作资源,提升系统可读性与可维护性。它将数据抽象为资源,使用标准HTTP动词(GET/POST/PUT/DELETE)对资源进行操作,确保行为一致、路径清晰。相比传统接口中使用动词导致的混乱,RESTful以名词化URI标识资源,如`/orders`,结合HTTP方法表达操作,实现解耦与标准化,便于前后端协作与系统扩展。

为什么需要RESTful
对于http接口的调用,其历程经历过原始servlet,到后面的struts,SpringMVC,对于后端的参数封装也逐渐从单个属性演变成对象封装,然而即使到现在,我们对于http接口的封装,仍有不少公司采用下述示例:
在这种模式下,开发人员一般将功能(或页面)聚合成一个controller,接口的路径定义也具备行为的特征,如对订单的操作,接口的定义一般形似(如删除、ID查询也可DELETE/GET):
功能
协议
接口
参数
新增
POST
/order/save
OrderSaveRequest
修改
POST
/order/update
OrderUpdateRequest
删除
POST
/order/delete
OrderDeleteRequest
ID查询
POST
/order/getById
OrderSingletonQueryRequest
复杂查询
POST
/order/get
OrderQueryRequest
在这种模式下我们对于订单协议的封装存在一个明显的问题:订单这个资源其行为是不规范的,同样是删除,有的人员定义为POST请求,有的是GET请求,资源表现的行为没有一个统一标准。更有甚者甚至会将order的功能封装成多个路径:save/order、save/product,这对于后续协议的维护简直就是灾难级别。因此我们需要一种设计规范,将程序员对于同一资源的行为封装做到规范统一。
总结为RESTful风格的设计拥有以下特点:结构清晰、统一标准、易于理解、扩展方便。
什么是RESTful
Resource Representational State Transfer:资源具象状态传输
RESTful是一个理念,是一个设计规范,而并非什么协议,其主要关键词如下:
资源
在RESTful的理念下,互联网中任意信息都可定义为资源,如上述对于订单的增删改查,在此就抽象为订单资源;资源会对应一个特定的URI,URI为每一个资源的地址或独一无二的标识符,对应订单就可抽象为:http://application/order。此时订单抽象为资源,资源对应唯一的URI,后续对此资源的操作都将遵循此URI。
表现层
针对资源对外输出的展现,这种呈现形式称之为表现层。以为本为例可以对外呈现为:json/xml/html等多种格式。
状态转化
客户端通过访问服务端,进行增删改查操作,从而对资源状态产生变化,这个过程便是:资源的状态转化。以http协议为例(RESTful不仅使用HTTP协议,只不过是经常以HTTP协议为衬托),客户端可通过一些操作让服务端的资源进行变化。整个过程即为:表现层状态转化。而HTTP协议中常见操作方式:GET/POST/PUT/DELETE
如何使用RESTful
资源
GET
PUT
POST
DELETE
一组资源的URI,比如http://example.com/resources/
列出URI,以及该资源组中每个资源的详细信息(后者可选)
使用给定的一组资源替换当前整组资源
在本组资源中创建/追加一个新的资源。该操作往往返回新资源的URL
删除整组资源
单个资源的URI,比如http://example.com/resources/142
获取指定的资源的详细信息,格式可以自选一个合适的网络媒体类型(比如:XML、JSON等)
替换/创建指定的资源。并将其追加到相应的资源组中。
把指定的资源当做一个资源组,并在其下创建/追加一个新的元素,使其隶属于当前资源。
删除指定资源
RESTful使用进阶
上面对于RESTful的理解和使用我们有了一个认知,但是如果不能在涉及之初就对资源进行合理的划分,RESTful将变成只是针对现有功能的包路径调整。因此我们最好可以在设计之初就引入对应的资源概念。
1.架构中引入资源(Resource)的概念
最常见的错误就是在URI中包含动词,比如URI=http://example.com/getOrder?orderId=1234,其实「资源」表示一种实体,所以应该是名词,动词应该放在HTTP协议中。而与此同时URI也有可能破坏HTTP GET的安全性和幕等性,比如某个客户端在http://example.com/updateOrder?id=1234&coffee=latte上执行GET(而不是POST),就能创建一笔新的咖啡订单(一个资源),按理来说GET请求不能改变服务的任何状态。
2.每一个URI代表一种资源,支持HTTP动词
此时使用多个URI的话,需要让不同的URI代表不同的资源(多个URI可能指向同一个Resource,而一个URI不能指向不同Resource),同时使用多个HTTP方法操作这些资源,例如使用POST/GET/PUT/DELET分别进行CRUD操作。这时候HTTP头和有效载荷都包含业务逻辑,例如HTTP方法对应CRUD操作,HTTP状态码对应操作结果的状态。我们现在看到的大多数所谓RESTful API做到的也就是这个级别。

相关文章
|
13天前
|
数据采集 人工智能 安全
|
8天前
|
编解码 人工智能 自然语言处理
⚽阿里云百炼通义万相 2.6 视频生成玩法手册
通义万相Wan 2.6是全球首个支持角色扮演的AI视频生成模型,可基于参考视频形象与音色生成多角色合拍、多镜头叙事的15秒长视频,实现声画同步、智能分镜,适用于影视创作、营销展示等场景。
657 4
|
8天前
|
机器学习/深度学习 人工智能 前端开发
构建AI智能体:七十、小树成林,聚沙成塔:随机森林与大模型的协同进化
随机森林是一种基于决策树的集成学习算法,通过构建多棵决策树并结合它们的预测结果来提高准确性和稳定性。其核心思想包括两个随机性:Bootstrap采样(每棵树使用不同的训练子集)和特征随机选择(每棵树分裂时只考虑部分特征)。这种方法能有效处理大规模高维数据,避免过拟合,并评估特征重要性。随机森林的超参数如树的数量、最大深度等可通过网格搜索优化。该算法兼具强大预测能力和工程化优势,是机器学习中的常用基础模型。
350 164
|
7天前
|
机器学习/深度学习 自然语言处理 机器人
阿里云百炼大模型赋能|打造企业级电话智能体与智能呼叫中心完整方案
畅信达基于阿里云百炼大模型推出MVB2000V5智能呼叫中心方案,融合LLM与MRCP+WebSocket技术,实现语音识别率超95%、低延迟交互。通过电话智能体与座席助手协同,自动化处理80%咨询,降本增效显著,适配金融、电商、医疗等多行业场景。
359 155

热门文章

最新文章