什么是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做到的也就是这个级别。

相关文章
|
4月前
|
消息中间件 人工智能 决策智能
AgentScope x RocketMQ:构建多智能体应用组合
AgentScope是阿里巴巴推出的开发者友好型多智能体框架,支持模块化、可定制的智能体应用开发。通过集成RocketMQ,实现高效、可靠的A2A通信,助力构建如“智能旅行助手”等复杂协作场景,提升开发效率与系统可扩展性。(238字)
|
4月前
|
监控 Java 调度
XXLJob定时任务概述
定时任务是基于时间表达式调度执行的任务,适用于定时对账、超时取消等场景。单体架构可使用轮询、Timer、ScheduledExecutorService、Quartz或SpringTask;分布式环境下需解决重复执行、故障转移等问题,主流方案有XXL-JOB、Elastic-Job、Saturn和ScheduleX。
|
4月前
|
人工智能 自然语言处理 API
全面认识MCP:大模型连接真实世界的“USB-C接口”
MCP(模型上下文协议)是Anthropic推出的AI“万能接口”,旨在统一大模型与工具、数据源的连接标准。它简化集成、提升任务处理能力,被誉为AI时代的“USB-C”。通过标准化通信,MCP让智能体可自主调用工具、执行复杂任务,推动AI应用迈向高效、安全、可扩展的新阶段。
|
4月前
|
消息中间件 人工智能 Linux
基于 RocketMQ 构建 高可靠 A2A 通信通道
A2A协议由Google于2025年发起,旨在构建跨厂商AI智能体的标准化通信机制。通过支持gRPC、JSON-RPC及RocketMQ异步通信,实现多智能体高效协同。基于RocketMQ的实现方案提供开箱即用的高可靠通信,支持任务分发、流式交互与状态查询,助力构建开放、可扩展的多智能体系统生态。(238字)
|
4月前
|
机器学习/深度学习 存储 自然语言处理
大模型基础概念术语解释
大语言模型(LLM)基于Transformer架构,通过海量文本训练,实现强大语言理解与生成。其核心包括注意力机制、位置编码、嵌入层等,支持万亿级参数与涌现能力,能完成翻译、问答等多任务,展现卓越泛化与推理能力。
|
4月前
|
XML 算法 安全
详解RAG五种分块策略,技术原理、优劣对比与场景选型之道
RAG通过检索与生成结合,提升大模型在企业场景的准确性与安全性。分块策略是其核心,直接影响检索效果与生成质量。本文系统解析五种主流分块方法:固定大小、语义、递归、基于结构和基于LLM的分块,对比其优缺点及适用场景,助力构建高效、可信的RAG系统,尤其适用于金融、医疗等高精度领域。(239字)
|
4月前
|
机器学习/深度学习 数据采集 人工智能
大模型训练方法与技术术语解释
预训练、微调、RLHF、思维链等技术共同构建大模型能力。预训练打基础,微调适配具体任务,RLHF融入人类偏好,思维链提升推理,少/零样本学习增强泛化,指令微调优化交互,自监督学习利用海量无标注数据,温度控制生成风格,蒸馏实现知识迁移,缩放定律指导模型扩展。这些核心技术推动大模型在多领域智能应用中持续突破,实现从理解到创造的跨越。(238字)
|
4月前
|
人工智能 JSON 数据挖掘
大模型应用开发中MCP与Function Call的关系与区别
MCP与Function Call是大模型应用的两大关键技术。前者是跨模型的标准协议,实现多工具动态集成;后者是模型调用外部功能的机制。MCP构建通用连接桥梁,支持多模型、跨平台协作,具备高扩展性与解耦能力;Function Call则依赖特定模型,直接解析意图并调用函数。两者在企业级系统中可协同工作:模型通过Function Call识别意图,转为MCP标准请求调用工具,兼顾智能解析与生态扩展。未来将趋向融合,形成“模型解析-协议传输-工具执行”的统一范式。
|
4月前
|
SQL Java 数据库连接
MyBatis分页
本文介绍MyBatis分页实现方式:RowBounds为内存分页,大数据易溢出;PageHelper等插件通过SQL改写实现物理分页,支持多数据库;还可借助subList或自定义拦截器分页。总结:大数据场景推荐物理分页,性能更优,优先于逻辑分页。(238字)
|
4月前
|
XML Java 数据格式
SpringBoot@Configuration使用总结
被@Configuration标注的类视为Spring配置类,等同于XML配置文件,通过@Bean定义Bean。结合AnnotationConfigApplicationContext可启动IOC容器,加载并管理所有Bean实例,包括配置类自身,实现基于注解的容器配置与组件注册。(238字)