在ASP.NET中搭建自定义WebHook Receiver的最优方案是什么？

可行替代方案 #

• 通用处理程序（ASHX Handler）方案
  这是完全匹配你需求的成熟方案，并非冷门用法。相比aspx页面，ASHX无需走完整的Web Form页面生命周期，资源占用极低，仅处理请求逻辑无需返回页面内容。
  实现逻辑：创建.ashx处理文件，仅放行POST请求，在处理逻辑中优先完成WebHook签名校验、请求来源校验等安全规则，业务处理完成后直接返回200状态码即可，无需输出任何响应内容。
  安全加固可叠加规则：限制仅允许WebHook提供方的IP段访问、添加请求速率限制、校验请求头的约定标识、校验请求体哈希签名。
• Web API/ApiController方案
  如果你当前的ASP.NET项目已经集成了MVC或Web API组件，直接用ApiController实现是更灵活的选择。
  实现逻辑：创建独立的WebHookController，仅开放POST类型的Action方法，配置自定义路由匹配你需要的WebHook回调地址。可以通过全局过滤器或Action过滤器统一实现签名校验、权限校验逻辑，无需在每个业务代码中重复编写，同时可以直接使用框架自带的模型绑定能力解析WebHook请求体，适配复杂的回调数据结构，性能和可维护性都优于aspx方案。
• Microsoft.AspNet.WebHooks.Receivers 简化使用方案
  该包的Azure相关组件属于可选依赖，你可以忽略文档中的Azure相关内容，仅使用其核心的自定义接收器基础逻辑，可省去底层请求解析、校验的通用代码开发量，如果不需要复杂扩展也可以直接使用。

搜索建议 #

你可以用以下关键词查找对应的实现教程和最佳实践：

• ASP.NET WebHook 接收端安全实现方案
• ASP.NET ASHX 处理WebHook请求示例
• ASP.NET Web API WebHook 签名校验实现
• ASP.NET WebHook 防重放攻击加固方案

内容的提问来源于stack exchange，提问作者CuriousCarnivore