我们有一个端点，当您发布创建新版本的资源时，它会返回 201 和新创建的资源的位置。它根据当前版本和发布的版本（使用类似 semver 的规则集）的比较来确定新版本号。
如果您发布的版本与现有版本相同，则不会更新版本号。在这种情况下我们应该返回什么？
- 即使我们在技术上没有创建任何东西，我们也可以返回 201。
- 我不想返回 409，因为它并不是真正的冲突，就像您发布具有相同 id 的内容时一样。如果您在现有版本略有不同的情况下发布了相同的内容，那么您会很高兴得到 201。
- 我们可以只返回 200，但这看起来很奇怪，并且增加了用户必须处理的响应代码
201 响应的幂等性重要吗？
还有更好的建议吗？
303 - 看看其他怎么样？看起来很合适。我提请你注意这句话
从规范https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
此方法的存在主要是为了允许 POST 激活的脚本的输出将用户代理重定向到选定的资源。
这听起来像是你想对我做的事。这是剩下的部分。
10.3.4 303 查看其他
可以在不同的 URI 下找到对请求的响应，并且应该使用该资源上的 GET 方法来检索。此方法的存在主要是为了允许 POST 激活的脚本的输出将用户代理重定向到选定的资源。新的 URI 不是原始请求资源的替代引用。 303 响应不得被缓存，但对第二个（重定向）请求的响应可能是可缓存的。
不同的 URI 应由响应中的位置字段给出。除非请求方法是 HEAD，否则响应实体应该包含一个简短的超文本注释，其中包含指向新 URI 的超链接。
Note: Many pre-HTTP/1.1 user agents do not understand the 303
status. When interoperability with such clients is a concern, the
302 status code may be used instead, since most user agents react
to a 302 response as described here for 303
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
