简介RESTful API设计规范.pdf是一份面向后端开发与API设计人员的精简参考手册系统梳理了REST架构的核心思想与落地约束解决接口命名混乱、版本控制缺失、不易扩展等常见痛点。资源仅1个PDF文件压缩包约173KB篇幅紧凑可作随查随用的规范文档。内容从资源抽象、无状态、分层系统等设计原则切入详解HTTP协议与HTTPS选择、专用域名部署、URL版本号管理并重点说明URL路径应使用复数名词、避免动词等命名规则同时清晰区分GET、POST、PUT、PATCH、DELETE的语义及典型示例此外还覆盖过滤参数如limit、offset、page与HTTP状态码类别便于开发者在实际项目中快速对照落地。该资源已有1300余人学习下载适合正在设计新接口或希望统一团队接口风格的开发者参考能有效提升系统可扩展性、安全性与维护效率。 RESTful API设计规范这个话题几乎每个后端开发都会接触但真正能把它讲透的并不多。很多团队接口写了不少回头一看有的叫/getUserInfo有的叫/queryUserList有的删除用GET有的更新用POST乱成一锅粥。我这些年经历过好几个项目的接口评审也接手过别人留下的“遗产接口”踩过的坑不少今天把积累下来的设计规范整理成一篇完整的实践笔记希望能帮那些正准备定接口规范、或者想重构老旧接口的团队少走弯路。先说清楚这篇文章适合谁看后端开发、前端开发、以及需要对接第三方接口的移动端或服务端同学。假如你正在设计一个新系统的接口或者公司内部没有一个统一的API规范可供参考这篇文章可以直接拿来当蓝本。我会从资源设计、HTTP方法语义、状态码、分页过滤排序、版本管理、认证安全、错误处理、性能优化这几个维度展开每一块都会说明“为什么这么设计”顺便把实际项目中容易踩的坑指出来。1. 资源的抽象是RESTful设计的起点别一上来就写URL很多人设计接口时习惯从“动作”出发比如“查询用户”、“添加订单”、“删除商品”于是URL就长成了/getUser、/createOrder、/deleteProduct的样子。这种设计在短期看没什么问题但一旦接口数量多起来维护成本会急剧上升因为每个动作都需要单独的URL前端调用时得记一堆路径后端想统一加缓存或权限控制也无从下手。RESTful的核心思想是把系统里的业务实体抽象成“资源”ResourceURL只表示资源本身不表示操作。操作交给HTTP方法去表达。比如一个用户资源对应的URL就是/users对这个URL执行GET表示查询用户列表执行POST表示新增用户对/users/{id}执行GET表示查单个用户PUT表示全量更新PATCH表示部分更新DELETE表示删除。这是RESTful设计的第一原则也是很多人容易忽略的先想清楚你的系统里有哪些资源再想资源和资源之间是什么关系最后才动手写URL。1.1 资源命名的三个实用准则资源命名直接影响接口的可读性和一致性我总结了三条实用准则用名词复数不用动词。/users好于/getUser/orders好于/createOrder。复数一方面语义清晰另一方面和HTTP方法组合后更自然GET /users列表、POST /users新增。全小写单词间用中划线-分隔。/user-profiles好于/user_profiles也好于/userProfiles。下划线在部分网关和日志系统里可能引发解析问题驼峰则影响URL的统一性。层级不要嵌套过深。/users/{id}/orders/{orderId}/items这种三层层级在真实场景里已经很难维护了。资源嵌套一般不超过两层超过后建议把子资源提升为独立资源比如订单项可以直接设计成/order-items通过查询参数order_id来过滤。1.2 子资源与关联资源怎么设计资源之间经常有关联关系比如一个用户有多条订单一个订单里有多个明细项。常见的做法是用嵌套URL表达这种从属关系GET /users/{id}/orders表示查某个用户下的订单列表。这种设计的优点是语义直白缺点是层级多了以后URL变长且不利于独立的权限控制。我的经验是当子资源脱离父资源没有独立意义时用嵌套当子资源可以被独立访问或管理时建议扁平化。比如/users/{id}/addresses适合嵌套因为脱离用户谈地址没有意义而/order-items适合扁平化因为后台管理系统中经常需要直接跨订单查明细。1.3 常见反模式动词URL与“动词名词”混用值得注意的是RESTful并不排斥所有动词。有些动作本质不是一个资源的CRUD而是一次操作比如“发送邮件”、“取消订单”、“点赞”。这类操作如果强行套资源模型会很别扭一种常见做法是把动作映射到子资源POST /orders/{id}/cancel。这其实是RESTful设计里一个被广泛接受的折中方案严格意义上cancel是一个动词但作为订单的一个子状态转换资源来看比POST /orders/{id}?statuscancelled更直观。真正的反模式是每个操作一个URL的做法比如/getUserById、/checkUserExist、/getOrderWithItems这种动词加名词的混用。这种设计一旦形成惯性接口会迅速膨胀而且无法享受HTTP方法带来的语义红利。2. HTTP方法与状态码语义对了接口就成功了一半HTTP协议本身已经定义了一套非常完整的方法和状态码体系RESTful设计的核心工作之一就是把业务操作精确映射到这套语义上。2.1 五个方法的使用边界GET查询必须幂等且无副作用。不论调用多少次资源状态不变返回结果一致。POST新增也用于触发复杂操作。非幂等每调用一次就创建一个新资源。PUT全量更新幂等。把整个资源替换成请求体里的内容。字段缺省会被重置为默认值或清空。PATCH部分更新只更新请求体里出现的字段。非严格幂等但从设计意图上是幂等操作。DELETE删除幂等。删除一个不存在的资源服务端应该返回404或204但不应报错。实际项目里最常见的误区是PUT和PATCH混用。我见过很多团队只有一个更新接口前端传什么字段后端就更新什么字段方法全部用POST路径叫/updateXxx。这种做法在接管老项目时经常遇到但并不妨碍后端新项目从一开始就用对方法。PUT和PATCH的区分并不复杂PUT要求客户端提交完整的资源表示PATCH允许只提交变更的字段。这个差异直接影响服务端对请求体的处理逻辑设计接口时一定要跟团队说清楚。2.2 状态码选型的经验清单状态码的选择直接影响客户端排查问题的效率。一套接口如果所有异常都返回200业务code前端每次都要解析body里的业务码才知道有没有出错这对调试很不友好。我的建议很明确HTTP状态码表达传输层的语义业务码表达业务层的语义二者各司其职。200GET、PUT、PATCH成功返回资源时使用。201POST创建成功时使用响应头里应包含新资源的Location地址。204操作成功但无返回体DELETE和部分PATCH操作适用。400参数错误、格式错误、字段缺失客户端的锅。401未认证没有提供凭证或凭证无效。403已认证但无权限比如普通用户访问管理端接口。404资源不存在URL错误或资源已被删除。409资源冲突比如创建已存在的用户名、版本号冲突。422语义错误参数格式正确但业务规则不允许比如订单金额为负数。429请求频率超限被限流了。500服务端未捕获的异常。502/503/504网关或服务不可用。这里特别想提醒一点400和422的区别。很多团队统一用400表示所有参数问题但体验上422更精确——400表示“你传的东西我解析不了”422表示“我能解析但你传的值不符合业务要求”。把这两个区分开前端定位问题时能省下很多沟通成本。2.3 别滥用200状态码我评审过不少接口习惯是无论成功失败一律返回HTTP 200然后在body里放一个code字段区分状态。这个设计最大的问题在于像Nginx、网关、日志系统这类中间层无法通过HTTP状态码感知业务错误。后端一个NullPointerException导致的失败经过网关层看到的还是200监控告警全部失效。反过来说如果HTTP状态码用得足够准确很多基础监控可以免费获得500的数量代表服务端异常429代表限流生效404说明有客户端在请求不存在的URL。这些数据对排查线上问题非常有价值。3. 容易被忽略的URL细节过滤、排序、分页与搜索查询类接口大概是日常开发中最常见的接口类型。但很多团队在过滤、排序、分页上各有各的写法导致前后端联调时频繁扯皮。这块设计规范如果能定得早后面省下的是全体协作成员的时间。3.1 查询参数设计过滤条件的标准写法过滤条件统一通过查询参数传递规则如下精确匹配直接用字段名GET /users?statusactive范围查询用字段名前缀GET /orders?price_min100price_max200时间范围用start_time和end_time值采用ISO 8601格式GET /orders?start_time2023-01-01T00:00:00Zend_time2024-01-01T00:00:00Z多值过滤用逗号分隔GET /users?statusactive,pending这套规则的好处是前端不用记每个接口的专门约定后端解析参数时也有一套通用逻辑。3.2 分页设计从page/pageSize到cursor分页大概是查询接口里最容易出问题的点。很多系统一开始数据量不大直接page1page_size20就上了。等到单表数据量突破百万级深分页的性能问题立刻暴露offset100000意味着数据库要扫描十万行再丢弃。这时候offset/limit分页已经撑不住了。行业里的通行进化路径是page/pageSize适合后台管理类、数据量可控、需要跳页的场景cursor分页适合C端Feed流、数据量持续增长的场景。Cursor分页的核心是客户端拿到的不再是页码而是一串编码了最后一条记录位置的值服务端根据这个值继续往下取。它的好处是翻页性能与页面深度无关缺点是用户无法直接跳转到任意页。设计规范时建议直接定义两种分页风格只要团队约定清楚上下文即可。返回分页结果时统一包一层元数据{ items: [], pagination: { page: 1, page_size: 20, total: 105, has_more: true } }3.3 排序与搜索排序参数统一叫sort格式为字段方向多字段逗号分隔sort-created_at,id表示按创建时间倒序再按id正序。负号或前缀-表示倒序这是GitHub API的实践被大量项目验证过可以直接抄。搜索和过滤要区分开过滤是结构化条件搜索是关键词模糊匹配。简单场景直接用q参数GET /products?q手机。需要更精确的搜索建议交给搜索引擎或数据库全文索引接口层的职责只负责透传关键词和定义返回格式。4. 连续迭代的命脉版本管理、兼容性与演进策略现实中几乎没有哪个接口从上线第一天就永远不变。业务要迭代需求会变化接口字段会调整如果不做版本管理一两次变更就能把前后端协作搅成一团。4.1 版本放哪里URL Path vs Header版本放URL是目前最主流的方式/api/v1/users和/api/v2/users。它的好处是直观可见任何人在浏览器里访问就看到版本号调试方便升级时旧的URL保留不动新旧版本可以共存迁移压力小。缺点是不够“优雅”严格意义上看URL会重复。版本放Header的方式Accept: application/vnd.myapp.v1json更符合REST的纯粹性URL保持干净但实际使用中调试体验很差浏览器直接访问根本看不到版本信息每次请求还要额外设置Header。对于大多数团队而言URL路径版本号是最务实的方案。4.2 兼容性设计什么操作算破坏性变更新增字段兼容只要客户端忽略未知字段即可。删除字段不兼容客户端还在用就被带崩了。修改字段类型不兼容比如原来count返回int现在改string。修改字段名称不兼容哪怕只是小写改大写。修改枚举值不兼容客户端可能没料想到新的枚举值。修改URL路径不兼容。修改请求参数的必填性不兼容客户端没传就会报错。降低返回数据范围考虑兼容性风险比如原来返回用户手机号现在脱敏了。凡是不兼容的变更都应该进入新版本接口。远程接口一旦对外发布契约就生效了尊重契约是团队协作的基本素养。4.3 优雅幂等这个细节很多人到线上才想起来做接口规范制定时幂等性设计往往是被一笔带过的点但真正到线上它会在接单、支付、消息推送这种场景里反复咬人。所谓幂等性是指同一个请求执行多次和执行一次的效果相同。POST创建类接口天然不幂等网络超时后客户端重试就可能创建出两条一模一样的订单。对策是引入幂等键机制客户端发起POST请求时在Header里带一个唯一值通常使用UUID服务端把这个键记录下来。如果收到相同键的重复请求直接返回第一次请求的结果而不重复创建。实现方式不复杂服务端拿幂等键查一下缓存命中就直接返回。这个设计尤其适合支付、下单、退款这类敏感操作。5. 安全与错误处理比想象中更有必要写进规范安全这块很多团队觉得“我们系统不大没人来攻击”等真出了问题才后悔。接口规范里明确认证、鉴权、敏感数据加密和错误返回格式是对全团队负责。5.1 认证鉴权别用GET传token推荐使用标准的Authorization头传递凭证。Token类型可以是从OAuth2.0拿到的bearer token也可以是JWT。需要注意的一个细节是JWT一旦签名发出在有效期内无法服务端主动失效所以设计时要考虑合适的过期时间和刷新机制系统里有“踢人下线”、“封禁用户”这类强失效需求时JWT并不是最优选择。5.2 错误响应体格式统一错误响应格式必须全局统一不能这个接口返回{msg: 错了}那个接口返回{message: error, code: 40001}前端写统一错误弹窗会崩溃。建议直接定义一套固定结构{ error: { code: 40001, message: 商品库存不足, details: [当前库存剩余5件, 你请求购买的数量为10] } }code是业务错误码message是给开发者看的原因details是可选的补充信息。日志和监控都要记录这个code后续做数据分析和告警都靠它。5.3 敏感字段与传输安全接口返回中涉及用户手机号、邮箱、身份证号、银行卡号等敏感信息时应默认脱敏。方案可以是由服务端直接返回脱敏后的字符串也可以返回原始值但要求客户端不得日志存储。规范里建议用前者服务端做一次字段脱敏处理客户端拿到什么用什么。例如手机统一返回138****8000只有在特定权限下或用户主动验证场景才通过专门接口返回明文。传输层全站HTTPS是底线没有商量的余地。顺便说一句容易被忽略的即使已是HTTPSURL里也不应携带手机号、身份证号这类隐私参数因为URL会被网关、浏览器历史、访问日志记录到隐私泄露风险远比POST请求体大。6. 响应结构与数据粒度一个稳定的“信封”有多重要响应结构的统一是前端组件抽象和复用最依赖的底层保障。如果每个接口返回格式五花八门前端就只能在每个请求函数里做特判。统一响应包装虽然谈不上多么新颖但它减少了大量隐性协作成本。6.1 外层信封与业务数据的解耦我推荐的做法是所有接口返回都包裹在一个统一结构里但HTTP状态码保持语义化。也就是说外层信封和业务数据要有明确的分层。成功时返回{ data: { id: 123, name: 张三 } }错误时返回{ error: { code: 40301, message: 无权限查看该订单 } }这种结构的好处在于前端可以统一处理最外层的data字段而把error交给拦截器全局处理。和“吃掉HTTP状态码”那种做法相比它既保留了传输层语义又给业务错误留了足够的表达空间。6.2 时间格式与字段命名统一时间统一用ISO 8601字符串带时区偏移2024-06-01T12:00:0008:00。不建议用时间戳因为不同语言解析时间戳还需要额外处理而ISO字符串带时区又可直接读。字段命名统一使用小写驼峰firstName或小写下划线first_name团队内任选一种但必须全量统一。考虑到大多数后端语言Java、Python习惯下划线移动端前端习惯驼峰建议由网关或框架层统一转换各端拿到手都舒服。布尔字段命名避免歧义is_active比active清楚has_permission比permission清楚。6.3 返回多余字段的问题接口返回里不应包含前端用不到的字段尤其是内表结构。拿一个列表接口举例/users返回用户数据是正常的但如果你把用户内部用到的角色权限树、加密盐值、内部备注都一股脑返回问题就不小了。一方面是数据泄露风险另一方面返回体过大也影响网络传输效率。好的做法是按场景拆接口比如GET /users/{id}返回详情GET /users/{id}/permissions返回权限而不是让一个接口承担所有职责。7. 规范落地层面的几个现实问题技术规范写得再好落不了地就等于白纸一张。这个章节聊几个我在推进规范落地时遇到的实际问题。7.1 接口文档如何维护规范的载体需要认真选。API文档工具目前用得比较多的是OpenAPISwagger、Apifox、Apigee这类的方案。我的建议是不管选什么工具文档必须能根据代码自动生成严禁手工维护Markdown接口文档——手工文档和代码不一致几乎是必然的。用OpenAPI描述接口的话建议开启Schema校验所有请求参数和响应体都能自动校验并暴露在文档里联调效率能提升一大截。7.2 接口评审一定要定这个流程接口设计从个人行为变成团队行为关键在评审。新接口写完后由后端TL或资深开发发起评审前端开发参与确认。评审的重点包括URL是否符合资源语义、参数命名是否规范、响应字段是否冗余、有没有破坏兼容性。评审不一定非要正式开会MR里提一个review请求就行但这步不能省。7.3 Demo先行规范的生命力在于快速验证如果你正要给团队推广这套规范我不建议一上来就写一本几十页的PDF下发。更好的做法是挑一个业务模块用这套规范把接口完整写出来前后端各出一个代表配合走一遍再收集问题迭代规范。规范和代码一样需要演进只有用起来了才能长成适合团队的样子。7.4 兼容老接口的策略存量老接口怎么处理是个现实难题。我经历过两种路线一种是“大版本重构一步到位”一种是“新增走规范存量逐步迁移”。两者各自的取舍是一步到位效率虽高但业务链路冻结周期长风险全押在迁一次逐步迁移的风险分散但老接口的存在会让规范看起来不彻底执行时会有人侥幸“还是按老写法快”。就个人经验来说后一种路线更稳妥。先把新增接口全部按规范来老接口用兼容层包一层等核心业务稳定了再分批迁移。强迫团队一次性把几百个老接口全部改造往往会造成业务阻塞反而给规范的推广制造阻力。8. 实战案例一个购物车接口的规范从0到1理论讲多了容易飘用一个具体案例把上述所有点串起来。8.1 场景定义假设我们要设计一个购物车相关的接口核心资源是购物车项CartItem关联资源是商品Product。用户需要查购物车列表、加入商品、修改数量、删除单项、清空购物车。8.2 接口清单GET /api/v1/cart-items获取购物车列表按加入时间倒序。POST /api/v1/cart-items加入购物车请求体携带product_id和quantity。PATCH /api/v1/cart-items/{id}修改数量请求体携带quantity。DELETE /api/v1/cart-items/{id}删除指定项。DELETE /api/v1/cart-items清空购物车可选条件参数cart_id。注意这里清空购物车也是DELETE但作用于集合资源。HTTP方法是允许对集合资源执行DELETE的语义是删除符合条件的一批资源。响应示例加入购物车成功后返回{ data: { id: 1001, product_id: 888, product_name: 无线机械键盘, price: 399.00, quantity: 1, created_at: 2024-06-01T12:00:0008:00 } }修改数量采用PATCH而不是PUT因为只传quantity一个字段服务器不需要关心其他字段的当前值。8.3 每一步对应的规范条款这个案例背后几乎覆盖了整篇文章的规范点资源命名采用复数名词路径包含版本号v1更新方法区分了PATCH和PUT集合删除用了DELETE方法响应结构统一包data时间格式是ISO 8601带时区的字符串。整套接口设计出来以后前端一个通用请求封装就能统一处理几乎不需要针对单个接口做特判。9. 这套规范不是终点按需裁剪我最初定规范时也想把每个点都覆盖到最后发现团队实际用到的远没有那么多。规范应当按需裁剪你的系统如果只做内部后台对复杂的认证授权、深度的版本兼容策略就没那么敏感如果你的系统要开放给第三方开发者使用那么文档质量、版本管理、稳定性要求就必须大幅提高。规范的定位应该是“底线共识”而不是“完美架构”。它要回答的是团队写接口时哪些必须一致哪些可以保持灵活。把必须一致的守住就已经避免了80%的协作矛盾。最后聊一个实操层面的小技巧把上面这些规范条目浓缩成一份checklist挂在接口评审的MR模板里。每次提测时作者自己先过一遍评审者照着checklist逐项打勾效率比重新阅读几十页PDF要高得多。这份README式的checklist我到现在还在用也是这篇文章能够成形的重要累积。本文还有配套的精品资源点击获取
RESTful API设计规范完整实践指南：从资源抽象到工程落地
简介RESTful API设计规范.pdf是一份面向后端开发与API设计人员的精简参考手册系统梳理了REST架构的核心思想与落地约束解决接口命名混乱、版本控制缺失、不易扩展等常见痛点。资源仅1个PDF文件压缩包约173KB篇幅紧凑可作随查随用的规范文档。内容从资源抽象、无状态、分层系统等设计原则切入详解HTTP协议与HTTPS选择、专用域名部署、URL版本号管理并重点说明URL路径应使用复数名词、避免动词等命名规则同时清晰区分GET、POST、PUT、PATCH、DELETE的语义及典型示例此外还覆盖过滤参数如limit、offset、page与HTTP状态码类别便于开发者在实际项目中快速对照落地。该资源已有1300余人学习下载适合正在设计新接口或希望统一团队接口风格的开发者参考能有效提升系统可扩展性、安全性与维护效率。 RESTful API设计规范这个话题几乎每个后端开发都会接触但真正能把它讲透的并不多。很多团队接口写了不少回头一看有的叫/getUserInfo有的叫/queryUserList有的删除用GET有的更新用POST乱成一锅粥。我这些年经历过好几个项目的接口评审也接手过别人留下的“遗产接口”踩过的坑不少今天把积累下来的设计规范整理成一篇完整的实践笔记希望能帮那些正准备定接口规范、或者想重构老旧接口的团队少走弯路。先说清楚这篇文章适合谁看后端开发、前端开发、以及需要对接第三方接口的移动端或服务端同学。假如你正在设计一个新系统的接口或者公司内部没有一个统一的API规范可供参考这篇文章可以直接拿来当蓝本。我会从资源设计、HTTP方法语义、状态码、分页过滤排序、版本管理、认证安全、错误处理、性能优化这几个维度展开每一块都会说明“为什么这么设计”顺便把实际项目中容易踩的坑指出来。1. 资源的抽象是RESTful设计的起点别一上来就写URL很多人设计接口时习惯从“动作”出发比如“查询用户”、“添加订单”、“删除商品”于是URL就长成了/getUser、/createOrder、/deleteProduct的样子。这种设计在短期看没什么问题但一旦接口数量多起来维护成本会急剧上升因为每个动作都需要单独的URL前端调用时得记一堆路径后端想统一加缓存或权限控制也无从下手。RESTful的核心思想是把系统里的业务实体抽象成“资源”ResourceURL只表示资源本身不表示操作。操作交给HTTP方法去表达。比如一个用户资源对应的URL就是/users对这个URL执行GET表示查询用户列表执行POST表示新增用户对/users/{id}执行GET表示查单个用户PUT表示全量更新PATCH表示部分更新DELETE表示删除。这是RESTful设计的第一原则也是很多人容易忽略的先想清楚你的系统里有哪些资源再想资源和资源之间是什么关系最后才动手写URL。1.1 资源命名的三个实用准则资源命名直接影响接口的可读性和一致性我总结了三条实用准则用名词复数不用动词。/users好于/getUser/orders好于/createOrder。复数一方面语义清晰另一方面和HTTP方法组合后更自然GET /users列表、POST /users新增。全小写单词间用中划线-分隔。/user-profiles好于/user_profiles也好于/userProfiles。下划线在部分网关和日志系统里可能引发解析问题驼峰则影响URL的统一性。层级不要嵌套过深。/users/{id}/orders/{orderId}/items这种三层层级在真实场景里已经很难维护了。资源嵌套一般不超过两层超过后建议把子资源提升为独立资源比如订单项可以直接设计成/order-items通过查询参数order_id来过滤。1.2 子资源与关联资源怎么设计资源之间经常有关联关系比如一个用户有多条订单一个订单里有多个明细项。常见的做法是用嵌套URL表达这种从属关系GET /users/{id}/orders表示查某个用户下的订单列表。这种设计的优点是语义直白缺点是层级多了以后URL变长且不利于独立的权限控制。我的经验是当子资源脱离父资源没有独立意义时用嵌套当子资源可以被独立访问或管理时建议扁平化。比如/users/{id}/addresses适合嵌套因为脱离用户谈地址没有意义而/order-items适合扁平化因为后台管理系统中经常需要直接跨订单查明细。1.3 常见反模式动词URL与“动词名词”混用值得注意的是RESTful并不排斥所有动词。有些动作本质不是一个资源的CRUD而是一次操作比如“发送邮件”、“取消订单”、“点赞”。这类操作如果强行套资源模型会很别扭一种常见做法是把动作映射到子资源POST /orders/{id}/cancel。这其实是RESTful设计里一个被广泛接受的折中方案严格意义上cancel是一个动词但作为订单的一个子状态转换资源来看比POST /orders/{id}?statuscancelled更直观。真正的反模式是每个操作一个URL的做法比如/getUserById、/checkUserExist、/getOrderWithItems这种动词加名词的混用。这种设计一旦形成惯性接口会迅速膨胀而且无法享受HTTP方法带来的语义红利。2. HTTP方法与状态码语义对了接口就成功了一半HTTP协议本身已经定义了一套非常完整的方法和状态码体系RESTful设计的核心工作之一就是把业务操作精确映射到这套语义上。2.1 五个方法的使用边界GET查询必须幂等且无副作用。不论调用多少次资源状态不变返回结果一致。POST新增也用于触发复杂操作。非幂等每调用一次就创建一个新资源。PUT全量更新幂等。把整个资源替换成请求体里的内容。字段缺省会被重置为默认值或清空。PATCH部分更新只更新请求体里出现的字段。非严格幂等但从设计意图上是幂等操作。DELETE删除幂等。删除一个不存在的资源服务端应该返回404或204但不应报错。实际项目里最常见的误区是PUT和PATCH混用。我见过很多团队只有一个更新接口前端传什么字段后端就更新什么字段方法全部用POST路径叫/updateXxx。这种做法在接管老项目时经常遇到但并不妨碍后端新项目从一开始就用对方法。PUT和PATCH的区分并不复杂PUT要求客户端提交完整的资源表示PATCH允许只提交变更的字段。这个差异直接影响服务端对请求体的处理逻辑设计接口时一定要跟团队说清楚。2.2 状态码选型的经验清单状态码的选择直接影响客户端排查问题的效率。一套接口如果所有异常都返回200业务code前端每次都要解析body里的业务码才知道有没有出错这对调试很不友好。我的建议很明确HTTP状态码表达传输层的语义业务码表达业务层的语义二者各司其职。200GET、PUT、PATCH成功返回资源时使用。201POST创建成功时使用响应头里应包含新资源的Location地址。204操作成功但无返回体DELETE和部分PATCH操作适用。400参数错误、格式错误、字段缺失客户端的锅。401未认证没有提供凭证或凭证无效。403已认证但无权限比如普通用户访问管理端接口。404资源不存在URL错误或资源已被删除。409资源冲突比如创建已存在的用户名、版本号冲突。422语义错误参数格式正确但业务规则不允许比如订单金额为负数。429请求频率超限被限流了。500服务端未捕获的异常。502/503/504网关或服务不可用。这里特别想提醒一点400和422的区别。很多团队统一用400表示所有参数问题但体验上422更精确——400表示“你传的东西我解析不了”422表示“我能解析但你传的值不符合业务要求”。把这两个区分开前端定位问题时能省下很多沟通成本。2.3 别滥用200状态码我评审过不少接口习惯是无论成功失败一律返回HTTP 200然后在body里放一个code字段区分状态。这个设计最大的问题在于像Nginx、网关、日志系统这类中间层无法通过HTTP状态码感知业务错误。后端一个NullPointerException导致的失败经过网关层看到的还是200监控告警全部失效。反过来说如果HTTP状态码用得足够准确很多基础监控可以免费获得500的数量代表服务端异常429代表限流生效404说明有客户端在请求不存在的URL。这些数据对排查线上问题非常有价值。3. 容易被忽略的URL细节过滤、排序、分页与搜索查询类接口大概是日常开发中最常见的接口类型。但很多团队在过滤、排序、分页上各有各的写法导致前后端联调时频繁扯皮。这块设计规范如果能定得早后面省下的是全体协作成员的时间。3.1 查询参数设计过滤条件的标准写法过滤条件统一通过查询参数传递规则如下精确匹配直接用字段名GET /users?statusactive范围查询用字段名前缀GET /orders?price_min100price_max200时间范围用start_time和end_time值采用ISO 8601格式GET /orders?start_time2023-01-01T00:00:00Zend_time2024-01-01T00:00:00Z多值过滤用逗号分隔GET /users?statusactive,pending这套规则的好处是前端不用记每个接口的专门约定后端解析参数时也有一套通用逻辑。3.2 分页设计从page/pageSize到cursor分页大概是查询接口里最容易出问题的点。很多系统一开始数据量不大直接page1page_size20就上了。等到单表数据量突破百万级深分页的性能问题立刻暴露offset100000意味着数据库要扫描十万行再丢弃。这时候offset/limit分页已经撑不住了。行业里的通行进化路径是page/pageSize适合后台管理类、数据量可控、需要跳页的场景cursor分页适合C端Feed流、数据量持续增长的场景。Cursor分页的核心是客户端拿到的不再是页码而是一串编码了最后一条记录位置的值服务端根据这个值继续往下取。它的好处是翻页性能与页面深度无关缺点是用户无法直接跳转到任意页。设计规范时建议直接定义两种分页风格只要团队约定清楚上下文即可。返回分页结果时统一包一层元数据{ items: [], pagination: { page: 1, page_size: 20, total: 105, has_more: true } }3.3 排序与搜索排序参数统一叫sort格式为字段方向多字段逗号分隔sort-created_at,id表示按创建时间倒序再按id正序。负号或前缀-表示倒序这是GitHub API的实践被大量项目验证过可以直接抄。搜索和过滤要区分开过滤是结构化条件搜索是关键词模糊匹配。简单场景直接用q参数GET /products?q手机。需要更精确的搜索建议交给搜索引擎或数据库全文索引接口层的职责只负责透传关键词和定义返回格式。4. 连续迭代的命脉版本管理、兼容性与演进策略现实中几乎没有哪个接口从上线第一天就永远不变。业务要迭代需求会变化接口字段会调整如果不做版本管理一两次变更就能把前后端协作搅成一团。4.1 版本放哪里URL Path vs Header版本放URL是目前最主流的方式/api/v1/users和/api/v2/users。它的好处是直观可见任何人在浏览器里访问就看到版本号调试方便升级时旧的URL保留不动新旧版本可以共存迁移压力小。缺点是不够“优雅”严格意义上看URL会重复。版本放Header的方式Accept: application/vnd.myapp.v1json更符合REST的纯粹性URL保持干净但实际使用中调试体验很差浏览器直接访问根本看不到版本信息每次请求还要额外设置Header。对于大多数团队而言URL路径版本号是最务实的方案。4.2 兼容性设计什么操作算破坏性变更新增字段兼容只要客户端忽略未知字段即可。删除字段不兼容客户端还在用就被带崩了。修改字段类型不兼容比如原来count返回int现在改string。修改字段名称不兼容哪怕只是小写改大写。修改枚举值不兼容客户端可能没料想到新的枚举值。修改URL路径不兼容。修改请求参数的必填性不兼容客户端没传就会报错。降低返回数据范围考虑兼容性风险比如原来返回用户手机号现在脱敏了。凡是不兼容的变更都应该进入新版本接口。远程接口一旦对外发布契约就生效了尊重契约是团队协作的基本素养。4.3 优雅幂等这个细节很多人到线上才想起来做接口规范制定时幂等性设计往往是被一笔带过的点但真正到线上它会在接单、支付、消息推送这种场景里反复咬人。所谓幂等性是指同一个请求执行多次和执行一次的效果相同。POST创建类接口天然不幂等网络超时后客户端重试就可能创建出两条一模一样的订单。对策是引入幂等键机制客户端发起POST请求时在Header里带一个唯一值通常使用UUID服务端把这个键记录下来。如果收到相同键的重复请求直接返回第一次请求的结果而不重复创建。实现方式不复杂服务端拿幂等键查一下缓存命中就直接返回。这个设计尤其适合支付、下单、退款这类敏感操作。5. 安全与错误处理比想象中更有必要写进规范安全这块很多团队觉得“我们系统不大没人来攻击”等真出了问题才后悔。接口规范里明确认证、鉴权、敏感数据加密和错误返回格式是对全团队负责。5.1 认证鉴权别用GET传token推荐使用标准的Authorization头传递凭证。Token类型可以是从OAuth2.0拿到的bearer token也可以是JWT。需要注意的一个细节是JWT一旦签名发出在有效期内无法服务端主动失效所以设计时要考虑合适的过期时间和刷新机制系统里有“踢人下线”、“封禁用户”这类强失效需求时JWT并不是最优选择。5.2 错误响应体格式统一错误响应格式必须全局统一不能这个接口返回{msg: 错了}那个接口返回{message: error, code: 40001}前端写统一错误弹窗会崩溃。建议直接定义一套固定结构{ error: { code: 40001, message: 商品库存不足, details: [当前库存剩余5件, 你请求购买的数量为10] } }code是业务错误码message是给开发者看的原因details是可选的补充信息。日志和监控都要记录这个code后续做数据分析和告警都靠它。5.3 敏感字段与传输安全接口返回中涉及用户手机号、邮箱、身份证号、银行卡号等敏感信息时应默认脱敏。方案可以是由服务端直接返回脱敏后的字符串也可以返回原始值但要求客户端不得日志存储。规范里建议用前者服务端做一次字段脱敏处理客户端拿到什么用什么。例如手机统一返回138****8000只有在特定权限下或用户主动验证场景才通过专门接口返回明文。传输层全站HTTPS是底线没有商量的余地。顺便说一句容易被忽略的即使已是HTTPSURL里也不应携带手机号、身份证号这类隐私参数因为URL会被网关、浏览器历史、访问日志记录到隐私泄露风险远比POST请求体大。6. 响应结构与数据粒度一个稳定的“信封”有多重要响应结构的统一是前端组件抽象和复用最依赖的底层保障。如果每个接口返回格式五花八门前端就只能在每个请求函数里做特判。统一响应包装虽然谈不上多么新颖但它减少了大量隐性协作成本。6.1 外层信封与业务数据的解耦我推荐的做法是所有接口返回都包裹在一个统一结构里但HTTP状态码保持语义化。也就是说外层信封和业务数据要有明确的分层。成功时返回{ data: { id: 123, name: 张三 } }错误时返回{ error: { code: 40301, message: 无权限查看该订单 } }这种结构的好处在于前端可以统一处理最外层的data字段而把error交给拦截器全局处理。和“吃掉HTTP状态码”那种做法相比它既保留了传输层语义又给业务错误留了足够的表达空间。6.2 时间格式与字段命名统一时间统一用ISO 8601字符串带时区偏移2024-06-01T12:00:0008:00。不建议用时间戳因为不同语言解析时间戳还需要额外处理而ISO字符串带时区又可直接读。字段命名统一使用小写驼峰firstName或小写下划线first_name团队内任选一种但必须全量统一。考虑到大多数后端语言Java、Python习惯下划线移动端前端习惯驼峰建议由网关或框架层统一转换各端拿到手都舒服。布尔字段命名避免歧义is_active比active清楚has_permission比permission清楚。6.3 返回多余字段的问题接口返回里不应包含前端用不到的字段尤其是内表结构。拿一个列表接口举例/users返回用户数据是正常的但如果你把用户内部用到的角色权限树、加密盐值、内部备注都一股脑返回问题就不小了。一方面是数据泄露风险另一方面返回体过大也影响网络传输效率。好的做法是按场景拆接口比如GET /users/{id}返回详情GET /users/{id}/permissions返回权限而不是让一个接口承担所有职责。7. 规范落地层面的几个现实问题技术规范写得再好落不了地就等于白纸一张。这个章节聊几个我在推进规范落地时遇到的实际问题。7.1 接口文档如何维护规范的载体需要认真选。API文档工具目前用得比较多的是OpenAPISwagger、Apifox、Apigee这类的方案。我的建议是不管选什么工具文档必须能根据代码自动生成严禁手工维护Markdown接口文档——手工文档和代码不一致几乎是必然的。用OpenAPI描述接口的话建议开启Schema校验所有请求参数和响应体都能自动校验并暴露在文档里联调效率能提升一大截。7.2 接口评审一定要定这个流程接口设计从个人行为变成团队行为关键在评审。新接口写完后由后端TL或资深开发发起评审前端开发参与确认。评审的重点包括URL是否符合资源语义、参数命名是否规范、响应字段是否冗余、有没有破坏兼容性。评审不一定非要正式开会MR里提一个review请求就行但这步不能省。7.3 Demo先行规范的生命力在于快速验证如果你正要给团队推广这套规范我不建议一上来就写一本几十页的PDF下发。更好的做法是挑一个业务模块用这套规范把接口完整写出来前后端各出一个代表配合走一遍再收集问题迭代规范。规范和代码一样需要演进只有用起来了才能长成适合团队的样子。7.4 兼容老接口的策略存量老接口怎么处理是个现实难题。我经历过两种路线一种是“大版本重构一步到位”一种是“新增走规范存量逐步迁移”。两者各自的取舍是一步到位效率虽高但业务链路冻结周期长风险全押在迁一次逐步迁移的风险分散但老接口的存在会让规范看起来不彻底执行时会有人侥幸“还是按老写法快”。就个人经验来说后一种路线更稳妥。先把新增接口全部按规范来老接口用兼容层包一层等核心业务稳定了再分批迁移。强迫团队一次性把几百个老接口全部改造往往会造成业务阻塞反而给规范的推广制造阻力。8. 实战案例一个购物车接口的规范从0到1理论讲多了容易飘用一个具体案例把上述所有点串起来。8.1 场景定义假设我们要设计一个购物车相关的接口核心资源是购物车项CartItem关联资源是商品Product。用户需要查购物车列表、加入商品、修改数量、删除单项、清空购物车。8.2 接口清单GET /api/v1/cart-items获取购物车列表按加入时间倒序。POST /api/v1/cart-items加入购物车请求体携带product_id和quantity。PATCH /api/v1/cart-items/{id}修改数量请求体携带quantity。DELETE /api/v1/cart-items/{id}删除指定项。DELETE /api/v1/cart-items清空购物车可选条件参数cart_id。注意这里清空购物车也是DELETE但作用于集合资源。HTTP方法是允许对集合资源执行DELETE的语义是删除符合条件的一批资源。响应示例加入购物车成功后返回{ data: { id: 1001, product_id: 888, product_name: 无线机械键盘, price: 399.00, quantity: 1, created_at: 2024-06-01T12:00:0008:00 } }修改数量采用PATCH而不是PUT因为只传quantity一个字段服务器不需要关心其他字段的当前值。8.3 每一步对应的规范条款这个案例背后几乎覆盖了整篇文章的规范点资源命名采用复数名词路径包含版本号v1更新方法区分了PATCH和PUT集合删除用了DELETE方法响应结构统一包data时间格式是ISO 8601带时区的字符串。整套接口设计出来以后前端一个通用请求封装就能统一处理几乎不需要针对单个接口做特判。9. 这套规范不是终点按需裁剪我最初定规范时也想把每个点都覆盖到最后发现团队实际用到的远没有那么多。规范应当按需裁剪你的系统如果只做内部后台对复杂的认证授权、深度的版本兼容策略就没那么敏感如果你的系统要开放给第三方开发者使用那么文档质量、版本管理、稳定性要求就必须大幅提高。规范的定位应该是“底线共识”而不是“完美架构”。它要回答的是团队写接口时哪些必须一致哪些可以保持灵活。把必须一致的守住就已经避免了80%的协作矛盾。最后聊一个实操层面的小技巧把上面这些规范条目浓缩成一份checklist挂在接口评审的MR模板里。每次提测时作者自己先过一遍评审者照着checklist逐项打勾效率比重新阅读几十页PDF要高得多。这份README式的checklist我到现在还在用也是这篇文章能够成形的重要累积。本文还有配套的精品资源点击获取
代码包深度解析与实践指南)
