php Facebook OAuth 错误：已达到应用程序请求限制

Facebook OAuth Error: Application request limit reached

提问by tnw

I'm trying to get facebook's example page working (again) which you can find here. I'm getting the following error:

我正在尝试让 facebook 的示例页面（再次）正常工作，您可以在此处找到。我收到以下错误：

Fatal error: Uncaught OAuthException: (#4) Application request limit reached thrown in C:\wamp\www\base_facebook.php on line 988

I've googled this and the problem seems to be easily fixed by using the steps outlined here. However, when I go to facebook.com/insights, my application isn't listed (I am logged in).

我在谷歌上搜索过这个问题，使用这里概述的步骤似乎很容易解决这个问题。但是，当我访问 facebook.com/insights 时，我的应用程序未列出（我已登录）。

The weirder part is that when I go to my app via Developers > My apps, I can go to the page of my app and click "Insights". This brings me to the Insights page for my app... but the diagnostic section is nowhere to be found. Can anyone help?

更奇怪的是，当我通过 Developers > My apps 转到我的应用程序时，我可以转到我的应用程序页面并单击“Insights”。这将我带到我的应用程序的见解页面...但无处可找到诊断部分。任何人都可以帮忙吗？

回答by Ja?ck

The outlined way of finding out why this happens is:

找出发生这种情况的原因的概述方法是：

1. Log into https://developers.facebook.com/apps/
2. The last app you've edited should already be loaded on the right side; if not, find your app on the left side and click the name.
3. Scroll down until you see the Insightssection and click See All.
4. From the menu on the left side, select API > Activity & Errors.

1. 登录https://developers.facebook.com/apps/
2. 您编辑的最后一个应用程序应该已经加载到右侧；如果没有，请在左侧找到您的应用并单击名称。
3. 向下滚动，直到看到该Insights部分，然后单击See All。
4. 从左侧的菜单中，选择API > Activity & Errors。

回答by Jesse Webb

The Facebook "Graph API Rate Limiting" docssays that an error with code #4is an app level rate limit, which is different than user level rate limits. Although it doesn't give any exact numbers, it describes their app level rate-limit as:

所述者“图形API速率限制”文档说，和代码中的错误#4是一个应用级别速率限制，这是比不同用户级的速率限制。虽然它没有给出任何确切的数字，但它描述了他们的应用程序级别的速率限制：

This rate limiting is applied globally at the app level. Ads api calls are excluded.

• Rate limiting happens real time on sliding window for past one hour.
• Stats is collected for number of calls and queries made, cpu time spent, memory used for each app.
• There is a limit for each resource multiplied by monthly active users of a given app.
• When the app uses more than its allowed resources the error is thrown.
• Error, Code: 4, Message: Application request limit reached

此速率限制在应用程序级别全局应用。不包括广告 API 调用。

• 速率限制在过去一小时的滑动窗口上实时发生。
• 统计数据包括调用次数和查询次数、花费的 CPU 时间、每个应用程序使用的内存。
• 每个资源乘以给定应用程序的每月活跃用户数都有一个限制。
• 当应用程序使用的资源超过其允许的资源时，将引发错误。
• 错误，代码：4，消息：达到应用程序请求限制

The docs also give recommendations for avoiding the rate limits. For app level limits, they are:

文档还给出了避免速率限制的建议。对于应用程序级别限制，它们是：

Recommendations:

• Verify the error code (4) to confirm the throttling type.
• Do not make burst of calls, spread out the calls throughout the day.
• Do smart fetching of data (important data, non duplicated data, etc).
  • Real-time insights, make sure API calls are structured in a way that you can read insights for as many as Page posts as possible, with minimum number of requests.
  • Don't fetch users feed twice (in the case that two App users have a specific friend in common)
  • Don't fetch all user's friends feed in a row if the number of friends is more than 250. Separate the fetches over different days. As an option, fetch first the app user's news feed (me/home) in order to detect which friends are more important to the App user. Then, fetch those friends feeds first.
• Consider to limit/filter the requests by using the following parameters: "since", "until", "limit"
• For page related calls use realtime updates to subscribe to changes in data.
• Field expansion allows ton "join" multiple graph queries into a single call.
• Etags to check if the data querying has changed since the last check.
• For page management developers who does not have massive user base, have the admins of the page to accept the app to increase the number of users.

建议：

• 验证错误代码 (4) 以确认节流类型。
• 不要突然打电话，全天分散电话。
• 智能获取数据（重要数据、非重复数据等）。
  • 实时洞察，确保 API 调用的结构方式使您能够以最少的请求读取尽可能多的主页帖子的洞察。
  • 不要两次获取用户提要（如果两个 App 用户有特定的共同朋友）
  • 如果好友数超过 250，则不要连续获取所有用户的好友提要。将获取时间分开。作为一种选择，首先获取应用用户的新闻提要（我/家），以检测哪些朋友对应用用户更重要。然后，首先获取那些朋友的提要。
• 考虑使用以下参数限制/过滤请求：“since”、“until”、“limit”
• 对于页面相关调用，使用实时更新订阅数据的变化。
• 字段扩展允许将多个图形查询“加入”到单个调用中。
• Etags 用于检查自上次检查以来查询的数据是否已更改。
• 对于没有海量用户群的页面管理开发者，让页面管理员接受应用程序以增加用户数量。

Finally, the docs give the following informational tips:

最后，文档提供了以下信息提示：

• Batching calls will not reduce the number of api calls.
• Making parallel calls will not reduce the number of api calls.

• 批量调用不会减少 api 调用的次数。
• 进行并行调用不会减少 api 调用的次数。

回答by user2571712

If you make a GET request to one of FB graph API endpoints that does not require access_token that does not mean you should not include it in request parameter. If you do as FB documentation says as do not include access_token than in FB server side it registers into your server machine. So limit (whatever amount is it exactly) can be reached very easily. If you however, put the user access token into the request (&access_token=XXXXXX) then requests register into the specific user, so the limit hardly ever be reached. You can test it with a simple script that makes 1000 requests with and without user access_token.

如果您向不需要 access_token 的 FB 图 API 端点之一发出 GET 请求，这并不意味着您不应将其包含在请求参数中。如果您按照 FB 文档中的说明执行操作，则不包含 access_token，而不是在 FB 服务器端，它会注册到您的服务器计算机中。所以可以很容易地达到限制（无论是多少）。但是，如果您将用户访问令牌放入请求中 (&access_token=XXXXXX)，则请求会注册到特定用户中，因此几乎不会达到限制。您可以使用一个简单的脚本对其进行测试，该脚本使用和不使用用户 access_token 发出 1000 个请求。

NOTE, FB app access token will not be sufficient as you will face the same problem: requests will be registered into app access_token that situation is alike making requests without access_token.

注意，FB 应用程序访问令牌是不够的，因为您将面临同样的问题：请求将注册到应用程序 access_token 中，这种情况类似于在没有 access_token 的情况下发出请求。