我已经用WepApi 2与主网站紧密结合编写了api。 我决定将它与其他网络应用程序分离，以使事情更加孤立。
我遵循了以下步骤：
广告属性，用于将当前使用旧网址的所有用户重定向到新网址。由于这些原因，我使用了307 status code，因为我们应该保留用户请求的动词并请求有效负载。
var response = request.CreateResponse(HttpStatusCode.TemporaryRedirect); //307
response.Headers.Location = new Uri($"{appConfig.ApiAppDomain}" + "/" + request.RequestUri.AbsolutePath + request.RequestUri.Query);
return response;
通常它很好用。客户端获得307，然后跟随Location标题中的URL。
问题在于：主要网络应用为https，新的API为http。当我使用邮递员时，它表现得很奇怪，并且用POST请求替换GET请求，同时请求所有请求的正文剪切。一点都不好而且很奇怪，因为307不允许更改方法和有效负载。
所以这里有几个问题：
答案 0 :(得分：3)
302,301等重定向只是GET请求。但是从技术上来说，浏览器可以发出POST请求。更多详细信息here。但是重定向不是一个好主意每次请求的往返行程。也可能导致其他问题，如跨域调用（如果您正在进行Ajax REST API调用或浏览器将验证所有资源仅从https加载（Mixed content warning）
处理此https的最佳方式是什么？＆gt; http重定向？
我们不应该进行重定向，因为它可能会导致很多问题，正如我上面解释的那样
它是否是一个好的解决方案？
在这种情况下，重定向不是一个好的解决方案。
将用户静默移动到新api url的最佳解决方案是什么？
在我看来，这种情况下的最佳解决方案是设置一个透明代理，它也可以执行https卸载。这也将对您的客户端进行零更改。这就是我们如何设置它。
在IIS中为任何进入API的请求设置反向代理。
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="ReverseProxyInboundRule2" stopProcessing="true">
<match url="api/(.*)" />
<action type="Rewrite" url="http://server2/api/{R:1}" logRewrittenUrl="true" />
<conditions>
</conditions>
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
在上面的urlrewrite规则中，如果请求的网址包含 api ，那么您将把请求转发给server2，这将超过http.So，直到此服务器请求将在https上发布并从那里开始将在http上发送到服务器2.但这不符合客户的知识。这将是本地请求（不是通过互联网），延迟可以忽略不计。所以流程将是这样的
浏览器=＆gt; https（https://example.com/api/products/2）=＆gt; HTTP（http://server2/api/products/2）
只是总结了这种方法的优点