Working with APIs can be both fun and a pain in the ass. This is a story of how I flirted with APIs and got schooled so bad.
Facebook’s Graph API
Facebook doesn’t have a search hashtag function but they have a search endpoint. Wait, they HAD a search post endpoint. Facebook apparently upgraded their API from 1.0 to 2.0. Unfortunately, they deprecated the “search post” function. Meaning, they don’t allow search posts/status anymore. It’s mentioned here: https://developers.facebook.com/docs/apps/upgrading.
Public post search is no longer available. (/search?type=post&q=foobar)
News Feed search is no longer available (/me/home?q=foobar)
🙁 So, there. It’s gone and I don’t know how I’m going to implement an improvised search hashtag function.
Twitter’s Search API
I (or we) can’t put up too many API calls to Twitter because of its rate limit. That’s fine. That’s normal. They have to. But that’s not fine if I want to get every tweet every X minutes. That’s going to be exhaustive. To be fair, Twitter has bumped the limit to 450 requests per 15-min. window which led me to this computation:
450 requests per 15 min 1440 mins / day So there are 96 15-minute chunks in a day 450 * 96 = 43,200 43,200 requests per day
I have to play within that certain number of requests. Talk about limitations!
In fairness to Twitter, they generously provided tips on how to avoid being rate-limited.
POINT OF EPIPHANY
If your business relies HEAVILY on others’ APIs, it can be both awesome and risky. Unless you have a special permission or contract with the API owner, you can get screwed at any random time. There’s only so much that we, as consumers of that API, can do.
API limitation is not a cliché.