DRF中request.POST、request.data与request.GET的具体差异问询

哈哈，刚上手DRF的时候我也被这三个玩意儿绕得头大！别慌，咱们一个个拆解，搞懂它们各自的定位和用法：

1. request.GET：专门捞URL里的查询参数 #

这货其实和Django原生视图里的request.GET没啥区别，就是用来提取URL末尾的查询字符串的——比如你访问/api/users?page=2&size=10，request.GET.get('page')就能拿到'2'。

• 不管你是GET、POST还是PUT请求，只要URL里带了查询参数，它都能拿到
• 本质是QueryDict类型，只能存字符串，默认只读（要修改得先调用.copy()）
• 场景：分页参数、筛选条件这类放在URL里的参数，一律用它

2. request.POST：只认表单编码的POST请求体 #

这个也是Django原生的属性，但局限性很大：

• 仅能处理POST请求中content-type为application/x-www-form-urlencoded（普通表单）或multipart/form-data（带文件的表单）的数据
• 如果你发的是JSON格式的POST请求（content-type: application/json），request.POST会是空的！因为它根本不认识JSON编码的请求体
• 同样是QueryDict类型，只读属性
• 场景：只有在处理传统表单提交（比如前端用form标签提交）的时候才会用到它，DRF写API的时候基本用不上

3. request.data：DRF给你开的全能外挂 #

这是DRF特意加的超级属性，专门为API开发量身打造：

• 支持所有请求方法：GET、POST、PUT、PATCH、DELETE都能用
• 兼容所有请求体类型：不管是表单、JSON、XML，甚至是文件上传，它都会自动解析成你能直接用的字典（或类似结构）
• 比如你发个JSON的POST请求，request.data直接就能拿到解析后的字典，不用自己手动去读request.body再转JSON
• 补充：当请求是GET方法时，request.data会直接返回request.GET的内容；非GET方法时，则解析请求体的数据。所以在DRF里，你可以统一用request.data来获取所有请求参数（不管是URL里的还是请求体里的），不用再区分GET和POST了！
• 场景：DRF开发API时，直接用request.data就完事儿，它是最常用的方式

一句话总结 #

• 要拿URL里的查询参数：用request.GET（或者request.data，因为GET请求时两者内容一致）
• 传统表单POST提交：request.POST能用，但DRF里更推荐用request.data
• 开发API处理各种请求体（JSON、表单、文件）：直接依赖request.data就够了

内容的提问来源于stack exchange，提问作者user10086707