使用路径、参数、正文和标头重定向 API 请求 [已关闭]

我想将旧 API 重定向到新 API [...]所有请求路径、参数、正文和标头

就 HTTP 重定向而言，旧服务器需要给出重定向响应（在您的情况下，我建议永久 301 重定向;HTTP 301）。

HTTP 重定向允许您将新域名与路径（也称为资源）和参数（也称为查询）一起传递。

然后，API 客户端需要重新发送请求（因为它已被 301 响应重定向到新 URL），然后该请求应包含路径、参数、正文和标头。

然后，移动设备不会受到影响（移动应用程序是客户端），因为到目前为止，它支持 HTTP 重定向。

但有一点需要注意：虽然即使是非常旧的 HTTP 客户端在 GET 请求和重定向方面也没有问题，但 POST 或 PUT 请求的行为可能因客户端和实现而异。例如，请求方法将从 POST 更改为 GET，并且不会重新发送正文或原始请求标头。

在您的方案中，这取决于移动应用中使用的 HTTP 客户端。如果在测试平台（测试平台）中运行该场景时发现移动应用程序在重定向中的行为不透明，则需要执行更好的策略。

最常见的情况是使旧端点充当新端点的反向代理，而不对客户端进行任何更改。然后，旧域/api 充当中间客户端，将请求（包括所有相关标头和正文）转发到新端点，等待响应，然后将响应转发给客户端。这也类似于 API 网关（或者更准确地说，它是一个 API 网关，只是只有一组有限的功能，仅用于将请求转发到新端点）。

尽管有大量的示例和文档，mod_rewrite是巫毒教。该死的 很酷的巫毒教，但仍然是巫毒教。

-- 布莱恩·摩尔

Apache HTTP 服务器是一个功能齐全的应用程序服务器，可以充当这样的 API 网关（单独用于重定向或反向代理）。您可以使用代理模块找到更多信息，一个好的起点可能是正向代理和反向代理/网关部分。

强大的重写模块（URL 的瑞士军刀）也具有很大的灵活性 操纵;注意 P|proxy 标志），它可能已经越过了你的方式，从概念上讲，可能已经在你的测试平台中探测了答案开头建议的 HTTP 重定向场景（注意 R|redirect 标志）。