【前端】HTTP请求方式:GET、POST 与其他请求方法详解

【前端】HTTP请求方式:GET、POST 与其他请求方法详解


文章目录


前言

在前后端分离开发中,最常见的问题之一就是:

  • GET 和 POST 有什么区别?
  • PUT、DELETE、PATCH 是干什么的?
  • 为什么有的接口用 POST 不能用 GET?
  • 为什么有时候 GET 能成功,POST 却报错?

本文系统整理 HTTP 请求方式的区别、原理与使用场景,结合 Vue + Axios 实际开发说明。


定义概念 + 缩写

一、HTTP 是什么?

HTTP(HyperText Transfer Protocol)

超文本传输协议,是浏览器与服务器之间通信的规则。


二、常见请求方式

方法作用是否修改数据
GET获取数据
POST提交数据
PUT更新数据(整体替换)
PATCH局部更新
DELETE删除数据
HEAD只获取响应头
OPTIONS查询支持的请求方式

性质


一、GET 请求

特点

  • 用于获取数据
  • 参数放在 URL 中
  • 可被缓存
  • 幂等(多次请求结果相同)

示例

axios.get('/api/user/list',{params:{page:1,pageSize:10}})

生成的请求:

GET /api/user/list?page=1&pageSize=10 

适用场景

  • 查询列表
  • 查询详情
  • 查询分页数据

二、POST 请求

特点

  • 用于提交数据
  • 数据放在请求体(body)
  • 不会被浏览器缓存
  • 常用于创建资源

示例

axios.post('/api/user/login',{username:'admin',password:'123456'})

数据不会出现在 URL 中。


适用场景

  • 登录
  • 表单提交
  • 创建资源
  • 复杂查询条件

三、PUT 请求

特点

  • 用于更新资源
  • 通常是“整体替换”
  • 幂等

示例

axios.put('/api/user',{id:1,name:'张三',phone:'123456'})

四、PATCH 请求

特点

  • 局部更新
  • 只修改某个字段
axios.patch('/api/user/1',{phone:'999999'})

五、DELETE 请求

特点

  • 删除资源
  • 一般通过 id 删除
axios.delete('/api/user',{params:{id:1}})

六、GET 与 POST 核心区别总结

对比项GETPOST
参数位置URLBody
安全性较低较高
数据长度有限制基本无限制
是否缓存
是否幂等
用途查询提交

使用步骤


一、在 Axios 中的标准写法

统一写法(推荐)

axios({method:'post',url:'/api/user/login',data:{username:'admin',password:'123456'}})

二、什么时候用 GET?

✔ 查询
✔ 不修改服务器数据
✔ 参数简单

例如:

GET/admin/category/page?page=1&pageSize=10

三、什么时候用 POST?

✔ 登录
✔ 提交表单
✔ 创建数据
✔ 查询条件复杂

例如:

POST/admin/employee/login 

四、为什么不能乱用 GET?

如果用 GET 做登录:

GET /login?username=admin&password=123456 

密码会暴露在浏览器地址栏:

  • 不安全
  • 会被浏览器记录
  • 会被代理服务器记录

所以登录必须用 POST。


五、RESTful 设计规范建议

操作方法
查询列表GET
查询单个GET
新增POST
修改PUT
局部修改PATCH
删除DELETE

总结

  1. GET 用于查询,不修改数据
  2. POST 用于提交,修改服务器数据
  3. PUT 是整体更新
  4. PATCH 是局部更新
  5. DELETE 是删除
  6. GET 参数在 URL,POST 参数在 body
  7. 登录、密码、敏感数据一定用 POST

一句话总结:

GET 是“看”,POST 是“改”

参考文献

[1] HTTP/1.1 协议规范
[2] Axios 官方文档

在这里插入图片描述


在这里插入图片描述

Read more

Flutter 三方库 flutter_adaptive_scaffold 的鸿蒙化适配指南 - 掌握一套代码适配全场景终端的自适应架构技术、助力鸿蒙应用构建从手机到平板及折叠屏的极致无缝交互体系

Flutter 三方库 flutter_adaptive_scaffold 的鸿蒙化适配指南 - 掌握一套代码适配全场景终端的自适应架构技术、助力鸿蒙应用构建从手机到平板及折叠屏的极致无缝交互体系

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 三方库 flutter_adaptive_scaffold 的鸿蒙化适配指南 - 掌握一套代码适配全场景终端的自适应架构技术、助力鸿蒙应用构建从手机到平板及折叠屏的极致无缝交互体系 前言 在 OpenHarmony 鸿蒙应用追求“万物互联、全场景覆盖”的伟大进程中,屏幕尺寸的多样性(从 6 英寸手机到 12 英寸平板,再到 2D/3D 模式切换的折叠屏)是每一位 UI 开发者必须正面迎接的挑战。如何在不为每种设备重写 UI 的前提下,实现导航栏自动从“底部”平滑流转到“侧边”?如何在宽屏模式下自动开启“双栏(Master-Detail)”布局?flutter_adaptive_scaffold 作为一个由 Flutter

By Ne0inhk
在 macOS 上通过 Docker 本地安装 OpenClaw 完整教程

在 macOS 上通过 Docker 本地安装 OpenClaw 完整教程

在 macOS 上通过 Docker 本地安装 OpenClaw 完整教程 什么是 OpenClaw?—— 你的本地 AI 智能体执行框架 OpenClaw 不仅仅是一个聊天机器人,而是一个功能强大的 AI 智能体执行框架。你可以把它想象成一个能自主思考、调用工具、并替你完成复杂任务的数字员工。 🧠 核心概念 * 智能体:OpenClaw 的核心大脑。它能理解你的自然语言指令,拆解任务,并决定调用哪些工具来执行。 * 网关:所有外部访问的入口。它负责处理 WebSocket 连接、管理设备配对、路由消息,是你与智能体交互的桥梁。 * 技能:智能体可调用的具体工具,比如访问文件、操作浏览器、发送消息、查询数据库等。你可以根据需要扩展技能库。 * 记忆:OpenClaw 可以存储对话历史和重要信息,实现长期记忆和上下文理解,让交互更连贯。 * 通道:连接外部聊天平台的渠道,如

By Ne0inhk
HarmonyOS6半年磨一剑 - RcIcon组件实战案例集与应用开发指南

HarmonyOS6半年磨一剑 - RcIcon组件实战案例集与应用开发指南

文章目录 * 前言 * 项目简介 * 核心特性 * 开源计划 * rchoui官网 * 文档概述 * 第一章: 基础用法实战 * 1.1 三种符号引用方式 * 1.2 应用场景 - 工具栏快速导航 * 第二章: 尺寸系统实战 * 2.1 响应式尺寸配置 * 2.2 应用场景 - 统一设计系统尺寸规范 * 第三章: 颜色系统实战 * 3.1 多彩色系配置 * 3.2 应用场景 - 状态指示系统 * 第四章: 双风格系统实战 * 4.1 线型与实底风格对比 * 4.2 应用场景 - 底部导航栏 * 第五章: 圆角系统实战 * 5.

By Ne0inhk
Flutter 组件 short_uuids 适配鸿蒙 HarmonyOS 实战:唯一标识微缩技术,构建高性能短 ID 生成与分布式索引架构

Flutter 组件 short_uuids 适配鸿蒙 HarmonyOS 实战:唯一标识微缩技术,构建高性能短 ID 生成与分布式索引架构

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 short_uuids 适配鸿蒙 HarmonyOS 实战:唯一标识微缩技术,构建高性能短 ID 生成与分布式索引架构 前言 在鸿蒙(OpenHarmony)生态迈向万物互联、涉及海量离线资源标识、蓝牙广播载荷(BLE Payload)及二维码数据极限压缩的背景下,如何生成既能保留 UUID 强随机性、又能极大缩减字符长度的唯一标识符,已成为优化存储与通讯效率的“空间必修课”。在鸿蒙设备这类强调分布式软总线传输与每一字节功耗敏感的环境下,如果应用依然直接传输长度达 36 字符的标准 UUID,由于由于有效载荷溢出,极易由于由于传输协议限制导致数据截断或多次分包带来的延迟。 我们需要一种能够实现高进制转换、支持双向编解码且具备低碰撞概率的短 ID 生成方案。 short_uuids 为 Flutter 开发者引入了将标准 UUID 转化为短格式字符串的高性能算法。它利用

By Ne0inhk