什么是RESTful

本文涉及的产品
RDS DuckDB + QuickBI 企业套餐,8核32GB + QuickBI 专业版
简介: 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做到的也就是这个级别。

相关文章
|
6月前
|
机器学习/深度学习 存储 自然语言处理
大模型基础概念术语解释
大语言模型(LLM)基于Transformer架构,通过海量文本训练,具备强大语言理解与生成能力。其核心组件包括注意力机制、位置编码与嵌入层,支持文本分割为Token进行处理。参数量达亿级以上,规模增长带来涌现能力,如复杂推理与跨任务泛化。混合专家模型(MoE)提升效率,推动模型持续扩展。
|
6月前
|
Linux 数据安全/隐私保护 虚拟化
虚拟机安装(CentOS7)
准备CentOS7镜像及VMware Workstation虚拟机工具,可从百度云下载(提取码:h1y9/bkz3)。使用VMware创建虚拟机,参考知乎教程完成安装。默认登录用户为root,密码由用户自定义设置。需准备一台具备运行虚拟机条件的电脑。
|
6月前
|
XML 算法 安全
详解RAG五种分块策略,技术原理、优劣对比与场景选型之道
RAG通过检索与生成结合,提升大模型在企业场景的准确性与安全性。分块策略是其核心,直接影响检索效果与生成质量。本文系统解析五种主流分块方法:固定大小、语义、递归、基于文档结构及LLM分块,对比其优缺点与适用场景,并探讨RAG在金融、医疗等高风险领域的可验证性挑战与前沿优化路径。
|
6月前
|
人工智能 自然语言处理 API
全面认识MCP:大模型连接真实世界的“USB-C接口”
MCP(模型上下文协议)是AI时代的“万能接口”,由Anthropic提出,旨在统一大模型与工具、数据源的连接标准。它简化集成、提升任务处理能力,支持多步骤流程与安全合规,推动AI智能体从对话走向行动,重塑AI应用生态。
|
6月前
|
消息中间件 人工智能 决策智能
AgentScope x RocketMQ:构建多智能体应用组合
AgentScope是阿里巴巴推出的开发者友好型多智能体框架,支持模块化、可定制的智能体应用开发。通过集成RocketMQ,实现高效、可靠的Agent间通信,助力构建如“智能旅行助手”等复杂协作场景,推动多智能体生态发展。(238字)
|
6月前
|
消息中间件 人工智能 Linux
基于 RocketMQ 构建 高可靠 A2A 通信通道
A2A协议由Google于2025年发起,旨在实现跨厂商AI智能体的标准化通信。基于RocketMQ构建的异步通信方案,支持任务分发、流式交互与状态同步,助力高效、可靠的多智能体协同系统落地,现已开源。
|
6月前
|
人工智能 JSON 数据挖掘
大模型应用开发中MCP与Function Call的关系与区别
MCP与Function Call是大模型应用的两大关键技术。前者是跨模型、标准化的通信协议,实现多工具动态集成;后者是模型调用外部函数的内置机制。MCP如同“蓝牙协议”,支持多设备互联互通,具备高兼容性与扩展性;Function Call则像“语音助手”,依赖特定模型完成具体任务。二者在功能上互补:MCP构建通用接口层,解耦模型与工具;Function Call负责意图解析与指令生成。
|
6月前
|
存储 NoSQL 关系型数据库
MongoDB相关概念
MongoDB是一款高性能、无模式的文档型数据库,适用于海量数据、高并发读写、事务要求不高的场景。广泛应用于社交、游戏、物流、物联网和视频直播等领域,支持水平扩展、高可用、复杂查询与快速迭代,开发运维成本低,是Web2.0时代理想的数据存储方案。
|
6月前
|
监控 Java 调度
XXLJob定时任务概述
定时任务指按时间表达式周期执行的任务,适用于对账、提醒、订单超时等场景。单体架构可用轮询、Timer、ScheduledExecutorService、Quartz、SpringTask等方案;分布式下需解决重复执行、动态调度、故障转移等问题,主流方案有XXL-JOB、Elastic-Job、ScheduleX等。
|
6月前
|
SQL 运维 分布式计算
如何做好SQL质量监控
SLS推出用户级SQL质量监控功能,集成于CloudLens for SLS,提供健康分、服务指标、运行明细、SQL Pattern分析及优化建议五大维度,助力用户全面掌握SQL使用情况,提升日志分析效率与治理能力。

热门文章

最新文章