Facebook的OAuth錯誤：應用程序請求限制達到

Question

我試圖讓Facebook的示例頁面的工作（再次），你可以找到here。我收到以下錯誤：

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

我GOOGLE了這一點，這個問題似乎使用概述here的步驟很容易固定。但是，當我訪問facebook.com/insights時，我的應用程序未列出（我已登錄）。

的離奇的是，當我通過開發人員>我的應用到我的應用程序，我可以去我的應用程序的頁面，然後點擊「見解」。這將我帶到我的應用程序的Insights頁面...但診斷部分無處可查。誰能幫忙？

Answer 1

找出爲什麼出現這種情況的概述的方式是：

1. 登錄到https://developers.facebook.com/apps/
2. 你編輯應該已經在右邊最後一個加載的應用程序;如果沒有，請在左側找到您的應用，然後單擊該名稱。
3. 向下滾動，直到你看到Insights部分，然後單擊See All。
4. 從左側的菜單中，選擇API > Activity & Errors。

Answer 2

如果您向其中一個不需要access_token的FB圖形API端點發出GET請求，這並不意味着您不應將其包含在請求參數中。如果你的FB文檔中所說的不包括access_token，那麼它將在FB服務器端註冊到你的服務器上。所以限制（不管數量是多少）都可以很容易達到。如果您然而，把用戶的訪問令牌到請求（& =的access_token XXXXXX）隨後註冊到特定的用戶，所以限制很少到達。您可以使用一個簡單的腳本對其進行測試，該腳本使用或不使用用戶access_token發出1000個請求。

注意，FB應用程序的訪問令牌是不夠的，你將面臨同樣的問題：請求將會被登記的應用程序是的access_token的情況是不一樣的access_token提交請求。

Answer 3

Facebook "Graph API Rate Limiting" docs表示代碼爲#4的錯誤爲app level rate limit，與user level rate limits不同。雖然它沒有給出任何確切的數字，它描述了它們的應用級速率限制爲：

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

該文檔還給出了避免速率限制的建議。對於應用程序級別的限制，它們分別是：

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.

最後，文檔提供以下信息提示：

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