2011-06-20 2 views
10

J'essaye d'obtenir la page d'exemple de facebook fonctionnant (encore) que vous pouvez trouver here. Je reçois l'erreur suivante:Facebook OAuth Erreur: limite de demande d'application atteint

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

J'ai googlé cela et le problème semble être facilement corrigé en suivant les étapes décrites here. Cependant, quand je vais sur facebook.com/insights, mon application n'est pas listée (je suis connecté). La partie la plus étrange est que lorsque je vais dans mon application via Developers> Mes applications, je peux aller à la page de mon application et cliquer sur "Insights". Cela m'amène à la page Insights pour mon application ... mais la section de diagnostic est introuvable. Quelqu'un peut-il aider?

+0

Lisons ci-dessous l'article [Application Facebook limite de demande atteint] [1] [1]: http://stackoverflow.com/questions/9272391/facebook-application-request-limit-reached – redwind

+0

Peut-on vérifier que json est activé sur votre serveur wamp – Warrior

Répondre

6

La façon décrite de savoir pourquoi cela se produit est:

  1. Connectez-vous à https://developers.facebook.com/apps/
  2. La dernière application que vous avez modifié devrait déjà être chargé sur le côté droit; sinon, trouvez votre application sur le côté gauche et cliquez sur le nom. Faites défiler la liste jusqu'à la section Insights et cliquez sur See All.
  3. Dans le menu de gauche, sélectionnez API > Activity & Errors.
+2

Que faire si vous utilisez graph.facebook.com/?id= ? –

2

Si vous faites une requête GET à l'une des extrémités de l'API graphique FB qui ne nécessite pas access_token cela ne signifie pas que vous devez pas inclure dans le paramètre de demande. Si vous faites comme la documentation FB dit que n'incluent pas access_token que dans le côté serveur FB il s'inscrit dans votre machine serveur. Donc, la limite (quel que soit le montant exact) peut être atteinte très facilement. Cependant, si vous placez le jeton d'accès utilisateur dans la requête (& access_token = XXXXXX), vous devez vous enregistrer auprès de l'utilisateur spécifique, de sorte que la limite soit rarement atteinte. Vous pouvez le tester avec un script simple qui fait 1000 requêtes avec et sans utilisateur access_token. REMARQUE, le jeton d'accès à l'application FB ne sera pas suffisant car vous serez confronté au même problème: les requêtes seront enregistrées dans l'app access_token, cette situation est semblable aux requêtes sans access_token.

3

Le Facebook "Graph API Rate Limiting" docs indique qu'une erreur avec le code #4 est app level rate limit, ce qui est différent de user level rate limits. donnent

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

Les docs également des recommandations pour éviter les limites de taux: Bien qu'il ne donne pas de chiffres exacts, il décrit leur taux limite comme niveau d'application. Pour les limites de niveau d'application, ils sont:

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.

Enfin, les documents donnent les conseils d'information suivants:

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

Salut merci d'ajouter ceci à ma question même si elle a 3 ans. Je ne sais pas si cela répond à ma question mais j'espère que cela aidera quelqu'un à l'avenir – tnw

+0

@tnw Moi aussi! Je suis en train de déboguer le même problème (code d'erreur '# 4') en ce moment et j'ai été mal conduit par beaucoup d'autres sources en disant que la limite était de" 600 appels par 600 secondes ". Cela peut être vrai, mais je crois que cela s'applique uniquement aux jetons d'accès utilisateur, pas aux jetons au niveau de l'application. –