RESTful 前后端传参参数格式总结

本文总结了RESTful API前后端交互的四种传参方式:路径参数(用于资源标识)、查询参数(用于筛选分页)、请求体参数(传输复杂数据)和请求头参数(处理元数据和认证)。


详细说明了各参数类型的特点、适用HTTP方法及使用场景,对比了JSON、FormData等请求体格式的优缺点,并提供了混合使用示例。


重点强调了参数选择原则:路径参数用于必需资源标识,查询参数用于可选操作,请求体用于完整数据,请求头用于元数据。


同时指出了常见误区,如避免在查询参数中传递敏感信息等,旨在帮助开发者设计更符合RESTful原则、高可读性和可维护性的API。


RESTful 前后端传参参数格式总结

参数类型 传参位置 格式示例 常见HTTP方法 特点与用途
路径参数 (Path Parameters) URL路径中 /users/123 /products/2024 GET, PUT, DELETE, PATCH 1. 用于标识特定资源 2. 是URL的一部分 3. 通常是必需的 4. 更符合RESTful资源定位语义
查询参数 (Query Parameters) URL问号后 /users?page=1&limit=20 /search?q=keyword&sort=desc GET 1. 用于筛选、排序、分页等可选参数 2. 键值对形式,用&连接 3. 长度有限制(因浏览器而异) 4. 可缓存
请求体参数 (Body Parameters) HTTP请求体中 JSON: {"name":"John", "age":30} Form: name=John&age=30 XML: <user><name>John</name></user> POST, PUT, PATCH 1. 传输数据量大,无长度限制 2. 支持复杂数据结构 3. 不可缓存(GET方法通常不应使用) 4. 需设置Content-Type头部
请求头参数 (Header Parameters) HTTP头部 Authorization: Bearer token123 Content-Type: application/json 所有方法 1. 用于元数据、认证、内容协商 2. 键值对形式 3. 大小有限制(通常8KB以内) 4. 自动包含在请求中

详细说明与最佳实践

1. 路径参数

  • 用途: 标识唯一资源或资源层次结构

  • 示例 : DELETE /api/users/{userId}/posts/{postId}

  • Content-Type: 不适用(参数在URL中)

2. 查询参数

  • 用途: 过滤、排序、分页、搜索等可选操作

  • 示例 : GET /api/products?category=electronics&minPrice=100&sort=price&page=2

  • Content-Type: 不适用

3. 请求体参数(常见格式对比)

格式 Content-Type 优点 缺点 适用场景
JSON application/json 1. 数据结构清晰 2. 前端JS原生支持 3. 可读性好 1. 相比二进制格式体积稍大 2. 不支持文件上传 REST API主要推荐格式,复杂数据结构
Form Data application/x-www-form-urlencoded 1. 浏览器原生支持 2. 简单键值对 1. 不支持嵌套结构 2. 值需要URL编码 简单表单提交,传统Web应用
Multipart multipart/form-data 1. 支持文件上传 2. 可混合文本和文件 1. 格式复杂 2. 体积较大 文件上传,包含文件的表单
XML application/xml 1. 严格的数据结构 2. 丰富的元数据支持 1. 冗长,体积大 2. 解析复杂 传统企业系统,SOAP API

4. 混合使用示例

复制代码
# 认证令牌在头部,ID在路径,分页在查询,更新数据在请求体
PUT /api/users/123/orders?notify=true
Authorization: Bearer xyz789
Content-Type: application/json

{
  "status": "shipped",
  "trackingNumber": "TRK123456"
}

选择原则总结

  1. 路径参数 : 用于必须的资源标识

  2. 查询参数 : 用于可选的过滤、排序等

  3. 请求体 : 用于创建/更新资源的完整数据

  4. 请求头 : 用于元数据认证信息


常见误区避免

  • ❌ 用查询参数传递敏感信息(会在日志、浏览器历史中暴露)

  • ❌ GET请求使用请求体传递参数(不符合HTTP语义,且可能不被支持)

  • ❌ 路径参数用于可选信息(会改变资源标识)

  • ✅ 保持参数位置的一致性(同类型参数总在相同位置)


这种传参结构设计能够使API更符合RESTful原则,提高可读性、可维护性和缓存效率。

相关推荐
ZengLiangYi11 小时前
用 ChatCrystal 学 Fastify:从零搭建 REST API
restful·express
taocarts_bidfans20 小时前
Taoify开放接口全解析:RESTful架构下,跨境开发者多系统对接实操指南
大数据·架构·restful·跨境电商·独立站
清水白石0082 天前
在 RESTful、RPC 与事件驱动之间做选择:高频内部调用与审计回放场景下的架构取舍
rpc·架构·restful
weixin199701080163 天前
[特殊字符] RESTful API 接口规范详解:构建高效、可扩展的 Web 服务(附 Python 源码)
前端·python·restful
码以致用7 天前
FastAPI 从入门到实践:构建规范的 RESTful API 服务
后端·restful·fastapi
若阳安好7 天前
【备忘录】正则表达式
后端·正则表达式·restful
AIFQuant9 天前
贵金属 API 避坑:黄金/白银行情接口常见陷阱(数据漂移、断点、延迟)
开发语言·python·websocket·金融·restful·贵金属
想你依然心痛11 天前
HarmonyOS 6(API 23)实战:打造“看见设计“的AR工业设计评审系统——基于Face AR情绪反馈 + Body AR手势操控的沉浸光感协作平台
ar·restful·harmonyos·悬浮导航·沉浸光感
bzmK1DTbd14 天前
Swagger API文档:Java RESTful服务的自动生成
java·开发语言·restful
想你依然心痛14 天前
HarmonyOS 6(API 23)实战:打造“空间交互式AR健身私教“——基于Face AR疲劳监测 + Body AR姿态识别的沉浸光感运动系统
ar·restful·harmonyos·悬浮导航·沉浸光感