HTTP之POST请求和GET请求
1. 简介
-
GET：用来获取数据。
-
POST：用来提交数据。
2. 基本区别
| 对比项 | GET | POST |
|---|---|---|
| 主要用途 | 从服务器获取资源（读操作） | 向服务器提交数据（写操作） |
| 参数位置 | 放在 URL 中（?key=value） | 放在请求体中（body） |
| 是否修改服务器数据 | 否 | 是 |
| 可见性 | 参数直接暴露在地址栏 | 参数在请求体内，不会显示在 URL |
| 缓存 | 浏览器和代理服务器可缓存 | 一般不会缓存 |
| 长度限制 | URL 长度有限（约2K~8K） | 理论上无限制（取决于服务器配置） |
| 幂等性 | ✅ 幂等（重复请求结果相同） | ❌ 非幂等（重复请求可能产生副作用） |
| 可被收藏/分享 | ✅ 可以 | ❌ 不可以 |
| 典型场景 | 获取网页、图片、数据 | 登录、提交表单、上传文件 |
3. 请求示例
🔹 GET 示例
GET /user/info?user_id=123 HTTP/1.1 Host: example.com
说明：
-
参数写在 URL 后面（查询字符串）
-
请求体为空
-
用于读取信息，不应改变服务器状态
🔹 POST 示例
POST /user/login HTTP/1.1 Host: example.com Content-Type: application/json { "username": "roson", "password": "123456" }
说明：
-
参数放在请求体（body）中
-
可提交复杂数据（如 JSON、文件）
-
用于登录、注册、上传等操作
4. 底层特性
| 特性 | GET | POST |
|---|---|---|
| 安全性（不修改资源） | ✅ 是 | ❌ 否 |
| 幂等性（多次执行结果相同） | ✅ 是 | ❌ 否 |
| 可缓存 | ✅ 是 | ❌ 否 |
| 可在浏览器地址栏触发 | ✅ 是 | ❌ 否 |
👉 所以浏览器在点击链接或刷新页面时，一般都会使用 GET。
5. 常见误区
| 误区 | 正确解释 |
|---|---|
| “POST 比 GET 更安全” | ❌ 其实都不安全，除非用 HTTPS；POST 只是不暴露在地址栏 |
| “GET 不能带参数” | ❌ 可以带参数（写在 URL） |
| “POST 比 GET 快” | ❌ 实际性能差异极小，取决于缓存机制与网络环境 |
| “GET 不能传 JSON” | ❌ 技术上可以，但不符合语义规范（GET 应仅获取资源） |
6. 可视化流程图
7. 总结
| 要点 | GET | POST |
|---|---|---|
| 用途 | 获取数据 | 提交数据 |
| 参数位置 | URL | 请求体 |
| 是否幂等 | 是 | 否 |
| 是否缓存 | 是 | 否 |
| 是否修改数据 | 否 | 是 |
| 常见用途 | 查询、分页 | 登录、注册、上传 |
8.在用户登录的时候，用GET和POST是不是都可以？
理论上都可以，但
正确、规范、安全的做法是：必须使用POST请求。
8.1 为什么“都可以”？
从技术角度讲，HTTP 协议并不禁止你用 GET 传账号密码。
例如下面这段其实是能登录的：
GET /login?username=roson&password=123456 HTTP/1.1 Host: example.com
服务器只要能解析参数，就能执行登录逻辑。
👉 所以“能用”没错。
8.2 但为什么“不能这么做”？
虽然 GET 可以传参，但登录操作属于 修改服务器状态 的行为（会创建 session/token 等），
而 GET 请求的语义是 “安全且幂等” ——
即：只读、不会改变服务器数据。
以下是用 GET 登录的严重问题：
| 问题 | 说明 |
|---|---|
| ⚠️ 账号密码暴露 | GET 参数会出现在地址栏、浏览器历史记录、代理服务器日志中。任何人都能看到。 |
| ⚠️ 缓存风险 | GET 请求可能被浏览器或代理服务器缓存，导致安全隐患。 |
| ⚠️ 容易被误触发 | 链接、刷新、爬虫抓取等都可能无意触发 GET 请求。 |
| ⚠️ 违反 HTTP 语义 | GET 语义上只读，用于“获取资源”，不是“执行操作”。 |
| ⚠️ CSRF 攻击风险高 | GET 请求更容易被第三方网站诱导触发。 |
8.3 为什么推荐用 POST
POST 的设计初衷就是：
“向服务器提交数据，改变服务器状态。”
登录操作恰好符合这个场景：
-
用户提交用户名 + 密码
-
服务器验证并生成 Token / Session
-
状态发生改变（用户登录）
示例：
POST /login HTTP/1.1 Host: example.com Content-Type: application/json { "username": "roson", "password": "123456" }
浏览器不会缓存请求体内容，也不会把它放在地址栏或历史记录里，更安全。
8.4 实际开发规范
| 项目 | 推荐方式 |
|---|---|
| 登录（Login） | ✅ 使用 POST |
| 注册（Register） | ✅ 使用 POST |
| 修改密码 | ✅ 使用 POST |
| 查询数据（获取信息） | ✅ 使用 GET |
| 登出（Logout） | ✅ 通常用 POST 或 DELETE |
8.5 形象对比
GET /login?user=roson&pwd=123456 🔴 密码出现在 URL！ 🔴 可被缓存/记录 🔴 不安全、不规范
POST /login Body: { "user":"roson", "pwd":"123456" } ✅ 安全、符合语义、可扩展
8.6 结论总结
| 方面 | GET | POST |
|---|---|---|
| 技术上是否可行 | ✅ 可以 | ✅ 可以 |
| 是否符合 HTTP 语义 | ❌ 不符合 | ✅ 符合 |
| 安全性 | ❌ 密码可能泄露 | ✅ 安全 |
| 是否可缓存 | ✅ 可能缓存 | ❌ 不缓存 |
| 是否推荐用于登录 | ❌ 不推荐 | ✅ 推荐且标准做法 |
👉 总结：
登录时，GET 能用，但不该用。
登录属于“提交敏感数据”，必须使用 POST。