何时将 CancellationToken 传递给控制器​​操作

Question

根据Scalability in ASP.NET Web APIs with Cancellation Tokens，CancellationTokens 应该仅用于 HTTP GET 请求：

\n

\n

可能产生副作用的请求（例如创建、更新或删除数据）也应该保持原样，因为如果请求在错误的时刻中断，则存在损害系统数据完整性的真正风险，尤其是在该操作有多个内部步骤。这使得我们只剩下无效请求，即那些只获取数据但在完成后不修改任何内容的请求，尽管指标和日志也一样。换句话说，如果实现正确，HTTP GET 请求。

\n

\n

Andrew Lock 在他的博客文章《在 ASP.NET Core MVC 控制器中使用 CancellationTokens》中也持有相同的观点：

\n

\n

如果请求修改状态，那么您可能不希望在方法中途停止执行。另一方面，如果请求没有副作用，那么您可能希望尽快停止（可能很昂贵）操作。

\n

\n

另一方面，根据在 .NET Core Web API 中使用 CancellationToken，鼓励将 CancellationToken 也传递给 POST / PUT / DELETE 请求：

\n

\n

其优点有很多，其中包括在创建、更新或删除时避免重复记录。

\n

\n

我记得在我过去使用过的几个 .NET Web 应用程序中，CancellationToken 作为参数传递给控制器​​中 GET / POST / PUT / DELETE 请求的所有操作。

\n

上述两个来源中谁是正确的。采用哪种最佳实践？就个人而言，我认为一旦创建/更新/删除数据涉及超过 1 个数据库表/1 个文件/等，向 POST、PUT 和 DELETE 请求添加 CancellationToken 就会出现问题，因为这可能会导致不一致。您对此有何看法？

\n