创建资源后执行重定向的正确HTTP响应状态码是什么？

这个场景的标准合规答案是303 See Other，不存在歧义，核心误区是对303的定义描述产生了误读，下面逐个拆解说明：

• 首先澄清303的定义误区
  文档中提到的“303重定向不指向请求的资源本身”，指的是重定向目标不能是你发起POST请求的那个处理接口本身，也就是不能把POST /widgets的请求直接重定向回/widgets让客户端重复提交创建请求。你场景里重定向的/widgets/1000是POST操作执行完成后新生成的独立资源实体，完全符合303定义里“指向操作确认页、操作结果对应资源表示页”的适用范围，没有任何冲突。

超文本传输协议（HTTP）303 See Other重定向响应状态码表示，重定向链接不指向请求的资源本身，而是指向其他页面（例如操作确认页、现实世界对象的表示页面等）。

• 逐个排除不适用的状态码
  • 302 Found：属于HTTP/1.0遗留的历史状态码，规范原本要求302重定向不得修改原请求方法，但早期几乎所有浏览器都违反规范，遇到POST后的302会自动改成GET发后续请求，行为不可预期。

尽管HTTP规范要求执行重定向时不得变更请求方法（及请求体），但并非所有用户代理都遵循该要求，目前仍存在这类实现缺陷的软件。因此建议仅将302状态码作为GET或HEAD方法的响应返回。
目前还在POST场景下用302的实现基本都是历史包袱，属于依赖客户端非标准行为的不严谨写法，不是规范层面的正确选项。

• 307 Temporary Redirect：是HTTP/1.1为了修正302的混乱专门新增的状态码，核心规则是必须100%保留原请求的方法和请求体发起重定向请求。如果在POST创建场景下返回307，客户端会向/widgets/1000再发起一次POST请求，和你“查看新创建的widget详情（需要发GET请求）”的需求完全相悖，直接排除。

大量网页浏览器对302状态码的实现违反了标准要求：无论原始请求使用何种方法（例如POST），都会将重定向后的新请求类型修改为GET。出于该原因，HTTP/1.1（RFC 2616）新增了303和307两个状态码，用于明确区分两种重定向行为：303强制将重定向后的请求类型改为GET，307则保留原始请求的方法不变。

• 核心状态码区分逻辑
  HTTP/1.1新增303和307，本质就是把原来302下混乱的两种行为做了明确拆分：
  • 如果你希望POST操作完成后，客户端用GET请求跳转到结果页面，就用303——这正是创建资源后跳详情的经典Post/Redirect/Get（PRG）模式的标准指定状态码。
  • 如果你希望临时更换请求接收地址，要求客户端把原请求（包括方法、请求体）原封不动发到新地址，就用307。
• 行业实践现状
  早年确实有大量系统图省事直接用302，刚好撞上大部分浏览器把POST后的302转成GET的非标准实现，能跑通流程，但这属于不规范的写法。目前所有主流Web框架的PRG模式默认实现，都已经统一使用303作为标准状态码。

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