这个问题我之前也碰到过，核心原因是HTTP重定向的方法处理规则和ASP.NET Core默认行为的冲突，咱们一步步来拆解解决：

为什么Delete动作的重定向会“循环到自身”？ #

你用RedirectToAction默认返回的是302 Found状态码，而不同HTTP请求方法下，客户端对302重定向的处理逻辑不一样：

• 对于POST请求，浏览器/大部分客户端会自动将后续请求转换成GET方法去访问重定向地址，刚好匹配你的[HttpGet("get-all")]动作，所以能正常工作。
• 对于DELETE请求，部分客户端（比如Postman、某些前端HTTP库）会保留原DELETE方法去请求重定向的get-all地址，但你的GetAll只接受GET请求，这就导致请求失败——如果你的路由配置有 fallback 或者客户端错误处理逻辑有问题，就会表现为“看似重定向到自身”的现象。

解决方案1：直接返回GetAll的结果（推荐，符合WebAPI设计） #

WebAPI的核心是数据交互，重定向是为浏览器导航设计的，并不适合API场景。更合理的做法是删除完成后，直接调用GetAll的逻辑返回结果：

[HttpDelete("{id}")]
public IActionResult Delete(int id) 
{
    // 执行你的删除逻辑
    _yourService.Delete(id);
    
    // 直接返回GetAll的结果，状态码保持200
    return GetAll();
}

解决方案2：强制用303状态码触发GET重定向 #

如果你一定要保留重定向逻辑，可以返回303 See Other状态码——这个状态码明确告诉客户端必须用GET方法去访问重定向地址，完全规避方法不匹配的问题：

[HttpDelete("{id}")]
public IActionResult Delete(int id) 
{
    // 执行删除逻辑
    _yourService.Delete(id);
    
    // 指定303状态码，确保客户端用GET请求GetAll
    return RedirectToAction("GetAll", statusCode: StatusCodes.Status303SeeOther);
}

额外提醒 #

如果是前端调用你的API，建议让前端在收到删除成功的响应（比如204 No Content）后，主动调用get-all接口刷新数据，这是API交互的常规模式，比依赖重定向更可靠。

内容的提问来源于stack exchange，提问作者Serhii Ka.