我正在指定ReST服务。我最近偶然发现了这个IETF草案文档，它可以被解释为建议ReST服务应该总是返回308。请注意，该文档似乎已经过期而没有被取代(我不太清楚IETF过程(。
我早些时候就有一个想法，那就是服务应该回归"；301永久移动"；对于GET和"；308永久重定向"；对于POST，以确保它不会被不适当地转换为GET(通过一些聪明的方法(。
301和308的使用似乎是用SHOULD和SHOULD NOTs而不是MUST和MUST NOTs来表达的；正确的事情；是哲学上的。
务实地说，301用于GET，308用于POST应该可以工作。308没有错，因为在写入时的当前修订包括响应于GET而产生的308的示例。现在有一个部署问题，如果客户端不理解308，它应该像对待300一样对待它(而不是301，这对我来说更有意义(，但308现在已经被广泛理解了，所以问题变成了你是否或为什么应该使用HTTP 301？
如果308本质上是301的bug修复，那么为什么HTTP/1.1中没有正式弃用301呢？在ReST或更普遍的HTTP中，是否存在将POST转换为GET以进行重定向的合法用例？
对于301 HTTP/1.1说：
注意：由于历史原因，用户代理可能会更改请求从POST到GET的方法。
为什么这是个好主意？它在任何地方仍然有效吗？
另请参阅：
- 什么'；HTTP 301和308状态代码之间的区别是什么？其提供了对301和308之间的差异的良好覆盖，但不覆盖这一点
- Restful API的客户端应该如何在POST时处理http状态301重定向
- 什么'；HTTP状态代码308是怎么回事
如果
308本质上是对301的错误修复，为什么301在HTTP/1.1中没有被正式弃用？
不，不是。
RFC 7538定义了308状态代码，它不会使301失效或废弃。它只是定义了另一个状态代码来填补RFC 7231上的空白，该代码没有定义永久状态代码307:的变体
+-------------------------------------------+-----------+-----------+
| | Permanent | Temporary |
+-------------------------------------------+-----------+-----------+
| Allows changing the request method from | 301 | 302 |
| POST to GET | | |
| Does not allow changing the request | - | 307 |
| method from POST to GET | | |
+-------------------------------------------+-----------+-----------+
实际上，我仍然看到301在SEO中被大量使用。我看到一些HTTP客户端无法识别308。
除了RFC，让我们看看Mozilla的MDN Web文档对301:的评价
超文本传输协议(HTTP(
301 Moved Permanently重定向状态响应代码指示所请求的资源已被明确移动到Location标头给定的URL。浏览器重定向到此页面，搜索引擎会更新资源链接(在"SEO"中，据说"链接果汁"会发送到新的URL(。即使规范要求在执行重定向时不更改方法(和主体(，也不是所有用户代理都与之一致——你仍然可以在那里找到这种类型的有缺陷的软件。因此，建议仅将
301代码用作GET或HEAD方法的响应，而将308 Permanent Redirect用于POST方法，因为在此状态下明确禁止更改方法。
现在看看Mozilla对308:的评价
超文本传输协议(HTTP(
308 Permanent Redirect重定向状态响应代码指示所请求的资源已被明确移动到Location标头给定的URL。浏览器重定向到此页面，搜索引擎会更新资源链接(在"SEO"中，据说"链接果汁"会发送到新的URL(。请求方法和正文不会更改，而
301有时可能会错误地更改为GET方法。注意：一些Web应用程序可能会以非标准的方式使用
308 Permanent Redirect并用于其他目的。例如，Google Drive使用308 Resume Incomplete响应向客户端指示未完成上传何时停止(参考(