Asp.net web api 何时使用HttpMessageHandler与ActionFilter？

看来这两者有着相似的目的。如果能看到一些例子，比如什么时候使用一种方法，什么时候使用另一种方法，优点和缺点，以及指出关键的区别，那就太好了

两者之间的主要区别在于它们的重点。消息 处理程序应用于所有HTTP请求。它们执行该功能 HTTP中介的。筛选器仅适用于以下请求： 发送到过滤器所在的特定控制器/操作 应用

当您想要改变行为时，应该使用MessageHandler 适用于绝大多数请求。应在以下情况下使用过滤器： 它们只适用于某些资源

---

处理程序和操作过滤器之间的一大区别是它们的执行阶段。动作过滤器在控制器分派和模型绑定发生后执行，因此您可以与处理请求的控制器实例交互，并可以直接访问传递给动作方法的类型化模型对象。我使用这种方法来执行请求/响应值的高级日志记录——因为我可以访问控制器，所以我能够记录关于如何处理请求的附加信息

消息处理程序在流程中执行得更早，操作起来比过滤器更接近原始请求/响应值（将处理程序中使用的HttpRequestMessage/HttpResponseMessage对象与过滤器中更丰富的HttpActionContext和HttpActionExecutedContext对象进行对比）。这使得它们在某些活动中可能更有效，例如，如果您试图确定是否需要提前终止请求。如果您知道应该拒绝请求，那么在WebApi基础设施开始实例化控制器、执行模型绑定等工作之前，处理程序将允许您这样做

---

另一个区别是处理程序是链接的，并且您可以更好地控制链的执行方式。尽管过滤器是按顺序调用的，但在一个过滤器中设置响应将有效地结束请求，从而阻止执行列表中的下一个过滤器。例如，如果第一个过滤器在模型为null时返回错误请求，第二个过滤器记录该请求，则在第一个过滤器生成错误请求后，将不会执行第二个过滤器。对于处理程序，调用内部处理程序并允许处理程序链正常运行仍然是可能的（尽管不一定可取！）。

更好的问题可能是何时使用HttpMessageHandler而不是全局ActionFilter。这似乎有点模糊。过滤器也可以应用于所有HTTP请求，如果它们作为全局过滤器添加的话。过滤器可以全局应用，MessageHandler可以应用于每个路由。因此，我认为这个答案并不令人满意。我认为使用过滤器的一个缺点是参数绑定将发生在OnAction执行之前，因此，如果您想在将数据交付给操作之前对其进行操作，则必须创建一些新的MediaTypeFormatter。