什么是RESTful

简介: RESTful是一种基于资源的API设计规范,主张用URI标识资源,HTTP动词(GET/POST/PUT/DELETE)定义操作,实现统一标准、结构清晰、易于维护的接口。避免动词化路径,提升系统可扩展性与可理解性。

为什么需要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风格的设计拥有以下特点:结构清晰、统一标准、易于理解、扩展方便。什么是RESTfulResource 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做到的也就是这个级别。

相关文章
Cocos Creator3.8 项目实战(五)背景无限滚屏效果如何实现
Cocos Creator3.8 项目实战(五)背景无限滚屏效果如何实现
898 0
|
Oracle Java 关系型数据库
SpringBoot整合ELK做日志(超完整)(上)
SpringBoot整合ELK做日志(超完整)(上)
648 0
|
2月前
|
XML 算法 安全
详解RAG五种分块策略,技术原理、优劣对比与场景选型之道
RAG通过检索与生成结合,提升大模型在企业场景的准确性与安全性。分块策略是其核心,直接影响检索效果与回答质量。本文系统解析五种主流分块方法:固定大小、语义、递归、基于文档结构及LLM分块,对比其优缺点与适用场景,并提出组合优化路径,助力构建高效、可信的RAG系统。
|
2月前
|
监控 Java 调度
XXLJob定时任务概述
定时任务指按时间表达式周期执行的任务,适用于对账、提醒、订单超时等场景。实现方式包括单体架构的轮询休眠、Timer、ScheduledExecutorService、Quartz及SpringTask;分布式架构面临重复执行、动态调整、故障转移等问题,主流方案有XXL-JOB、Elastic-Job、Saturn和ScheduleX等。
|
2月前
|
人工智能 JSON 数据挖掘
大模型应用开发中MCP与Function Call的关系与区别
MCP与Function Call是大模型应用的两大关键技术。MCP为模型与外部工具提供标准化通信协议,实现跨模型、跨平台集成;Function Call则是模型调用外部函数的内置机制。前者如“蓝牙协议”,支持多设备互联,后者像“语音助手”,限于单机操作。两者在功能上互补:MCP支持工具热插拔、权限控制与远程调用,适用于企业级复杂系统;Function Call开发简单,适合快速验证单一模型能力。未来趋势将走向融合,形成“模型解析-协议传输-工具执行”的分层架构,推动AI应用生态标准化发展。
|
4月前
|
人工智能 生物认证 数据安全/隐私保护
AI检测器:我们如何识别机器生成的内容?
AI检测器:我们如何识别机器生成的内容?
309 3
|
8月前
|
存储 安全 Java
Java 集合面试题从数据结构到 HashMap 源码剖析详解及长尾考点梳理
本文深入解析Java集合框架,涵盖基础概念、常见集合类型及HashMap的底层数据结构与源码实现。从Collection、Map到Iterator接口,逐一剖析其特性与应用场景。重点解读HashMap在JDK1.7与1.8中的数据结构演变,包括数组+链表+红黑树优化,以及put方法和扩容机制的实现细节。结合订单管理与用户权限管理等实际案例,展示集合框架的应用价值,助你全面掌握相关知识,轻松应对面试与开发需求。
394 3
|
安全 测试技术 Go
Goland完全攻略 新手快速上手
Goland完全攻略 新手快速上手
535 0
|
XML 前端开发 Java
Web开发: 什么是Servlet和JSP?
Web开发: 什么是Servlet和JSP?
525 0
|
Kubernetes 应用服务中间件 网络安全
Kubernetes证书类型和适用场景
Kubernetes证书类型和适用场景