什么是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月前
|
机器学习/深度学习 存储 自然语言处理
大模型基础概念术语解释
大语言模型(LLM)基于Transformer架构,通过海量文本训练,具备强大语言理解与生成能力。其核心组件包括注意力机制、位置编码与嵌入层,支持文本分割为Token进行处理。参数量达亿级以上,规模增长带来涌现能力,如复杂推理与跨任务泛化。混合专家模型(MoE)提升效率,推动模型持续扩展。
|
4月前
|
消息中间件 人工智能 Linux
基于 RocketMQ 构建 高可靠 A2A 通信通道
A2A协议由Google于2025年发起,旨在实现跨厂商AI智能体的标准化通信。基于RocketMQ构建的异步通信方案,支持任务分发、流式交互与状态同步,助力高效、可靠的多智能体协同系统落地,现已开源。
|
4月前
|
消息中间件 人工智能 决策智能
AgentScope x RocketMQ:构建多智能体应用组合
AgentScope是阿里巴巴推出的开发者友好型多智能体框架,支持模块化、可定制的智能体应用开发。通过集成RocketMQ,实现高效、可靠的Agent间通信,助力构建如“智能旅行助手”等复杂协作场景,推动多智能体生态发展。(238字)
|
4月前
|
Linux 数据安全/隐私保护 虚拟化
虚拟机安装(CentOS7)
准备CentOS7镜像及VMware Workstation虚拟机工具,可从百度云下载(提取码:h1y9/bkz3)。使用VMware创建虚拟机,参考知乎教程完成安装。默认登录用户为root,密码由用户自定义设置。需准备一台具备运行虚拟机条件的电脑。
|
4月前
|
人工智能 JSON 数据挖掘
大模型应用开发中MCP与Function Call的关系与区别
MCP与Function Call是大模型应用的两大关键技术。前者是跨模型、标准化的通信协议,实现多工具动态集成;后者是模型调用外部函数的内置机制。MCP如同“蓝牙协议”,支持多设备互联互通,具备高兼容性与扩展性;Function Call则像“语音助手”,依赖特定模型完成具体任务。二者在功能上互补:MCP构建通用接口层,解耦模型与工具;Function Call负责意图解析与指令生成。
|
4月前
|
SQL 安全 关系型数据库
了解SQL注入
SQL是用于管理数据库的结构化查询语言,广泛应用于MySQL、Oracle等系统。其语法通用,但各数据库有特定细节。SQL常为Web应用提供后端支持,通过用户输入动态构建语句。若缺乏严格输入验证,易遭SQL注入攻击,导致身份绕过、数据泄露、远程命令执行等严重后果。OWASP将其列为头号Web威胁。攻击者可通过构造恶意输入篡改SQL逻辑,如利用`' OR '1'='1`绕过登录验证,或使用`--`注释符闭合原语句。
|
4月前
|
设计模式 Linux 开发工具
每日必会3
熟悉Docker部署,掌握docker run、Dockerfile及docker-compose集群部署。熟练使用镜像与容器相关命令,如pull、push、run、exec、logs等。常用Linux命令包括ls、cd、grep、ps、top、chmod、find、ssh、scp、wget、systemctl等,重点掌握权限、进程与服务管理。查日志常用cat | grep,大日志避免vim。了解SpringMVC执行流程、设计模式与常用注解。
|
4月前
|
存储 数据库
数据库设计三范式
第一范式要求字段原子性,不可再分;第二范式要求消除部分依赖,一张表只描述一件事;第三范式要求消除传递依赖。三者旨在减少数据冗余、提升维护效率,但实际设计应结合业务需求灵活应用,不必拘泥范式。
每日必会7
CAP理论指出分布式系统中一致性(C)、可用性(A)、分区容错性(P)不可兼得,只能三选二。由于网络故障不可避免,P必须保证,因此只能在A和C间权衡。BASE理论是对此的实践补充,主张基本可用、软状态、最终一致性。Seata AT模式通过全局事务ID(XID)协调分支事务注册与提交,实现分布式事务一致性。MQ防丢消息:生产端确认、持久化、消费端ACK;防重复消费:幂等设计;防积压:扩容、批量处理、限流削峰。
|
4月前
|
SQL Dubbo Java
线程池:故障梳理总结
本文从故障与技术双重视角,总结线程池满导致服务不可用的常见成因及应对策略。涵盖数据库慢SQL、锁争用、连接池配置不当等典型问题,结合真实案例剖析根源,并提出fast-fail、流控、背压等防护建议,助力开发者提升系统稳定性。