Question

我目前正在我的应用程序中测试throttling。我对Graph-API的某些请求使用Batch端点。

我从文档中了解到，目前Outlook的限制是每个用户每应用每10分钟有1万个请求（exchange doc和blog）。

为了产生节流的情况，我确实发送了太多请求（>10.000）到：

/v1.0/users/{a_userId}/contacts/{a_contactId}/

->如预期的那样，对Outlook资源的所有其他操作均受到限制（获取日历，获取联系人，...）

但是当我发送批处理请求时，所有对Outlook端点的请求都已成功执行

示例请求：

POST https://graph.microsoft.com/v1.0/$batch
{
  "requests": [
    {
      "id": "1",
      "method": "GET",
      "url": "/users/{a_userId}/contacts/{a_contactId}/"
    }
    // ... some more request items
  ]
}

我在两个测试中都使用了相同的用户和应用。
对于批处理而言，似乎存在不同的节流行为。

文档没有为批处理请求指定任何/不同的行为。所以我的问题是，在这种情况下节流将如何表现？尤其是限制很重要。

例如如果我通过批处理向Outlook终结点发送了太多请求，那么只会限制对Outlook终结点的请求，还是会限制整个批处理终结点（即使是对其他资源的请求，对所有资源的每个批处理请求项也会被限制）例如onedrive）？

修改：

我的问题是直接访问资源时我被限制了但是在批处理终结点上执行相同的请求确实可行。

由于缺乏有关批处理方面的限制的文档，我认为无论资源以何种方式访问，“限制”仅对每个资源“计数”一次。但是，仅在直接访问资源时才受到限制。因此，我不确定Batch enpoint的确切节流行为。

节流是否根据我的要求进行单独计算？
例如。假设对Exchange资源正确吗？
直接要求限制10k / 10min
按批次要求加10k / 10分钟
理论上可能产生20k / 10min的请求？

Answer 1

10k / 10分钟的限制是特定于Exchange资源（邮箱，组等）的限制。不幸的是，我们在其他产品（如OneDrive / Sharepoint）上还没有“见面”，因此它们目前有自己的节流限制。我们更好：P（j / k）。

因此，为回答您的问题，与其他工作负载相比，Exchange资源分别受到限制。如果您限制访问Exchange邮箱，则不会自动限制OneDrive请求。但这实际上是有道理的。即使在Exchange中，您的限制也取决于您的 AppId +目标邮箱。因此，如果您访问邮箱A并受到限制，即使使用同一应用程序，也不会访问邮箱B。因此，您可以将OneDrive视为另一个目标。

批处理端点中的限制行为

1 个答案: