我已经更换了托管提供商并获得了新域名。
我想将旧 API 重定向到新 API，如何在不影响移动应用程序的情况下实现这一目标？
例如：
https://old.example.com/api/example
至
https://new.example.app/api/example
包含所有请求路径、参数、正文和标头
我想将旧 API 重定向到新 API [...] [w]所有请求路径、参数、正文和标头
就 HTTP 重定向而言，旧服务器需要给出重定向响应（在您的情况下，我建议使用 permanent 301 重定向；HTTP 301）。
HTTP 重定向允许您传递新域名以及路径（也称为资源）和参数（也称为查询）。
API 客户端随后需要重新发送（因为它已被 301 响应重定向到新 URL）请求，该请求应包含路径、参数、正文和标头。
移动设备不会受到影响（移动应用程序是客户端），因为它支持 HTTP 重定向。
但有一个警告：虽然即使是非常旧的 HTTP 客户端在 GET 请求和重定向方面也没有问题，但 POST 或 PUT 请求的行为可能因客户端和实现而异。例如，请求方法将从 POST 更改为 GET，并且正文或原始请求标头不会重新发送。
在您的场景中，这取决于移动应用程序中使用的 HTTP 客户端。如果在测试台 (Testbed) 中运行场景显示移动应用程序在重定向方面表现不透明，则您需要采取更好的策略。
最常见的可能是让旧端点充当新端点的转发代理。然后，旧域/api 充当中间客户端，将请求（带有所有相关标头和正文）转发到新端点，等待响应，然后将响应转发到客户端。这也类似于 API 网关（或者更准确地说，它是一个 API 网关，只有一组有限的功能，仅用于将请求转发到新端点）。
Apache HTTP 服务器是一个功能齐全的应用程序服务器，可以充当这样的 API 网关（单独用于重定向或转发代理）。您可以使用 代理模块 找到更多信息，一个好的起点可能是 正向代理和反向代理/网关部分。
强大的Rewrite 模块（注意 P|proxy
标志）也具有很大的灵活性，它可能已经跨越了您的道路，并且从概念上讲可能已经在您的测试台中针对建议的 HTTP 重定向场景进行了探测。答案的开头（注意
R|redirect标志）。