Hi! I am starting to dive deeper into the current challenge – Programming Twitter API. Just a quick basic review of the API requirements before we make any calls! Oh wait, why not take a look at what an API call looks like?
If you type the URL shown in that snapshot into your browser of choice, you will see something like this displayed:
Ugh! How messy is that? I really hope you will be able to look through that mess and identify some information that could help you build something useful!
Now back to basics: Rate Limiting – Twitter allows up to 150 unauthorized calls per hour (it could be per an application or IP address). Authorized calls have a limit of 350 per hour! You might say, well, 150 is a little smaller if you think of it. How do I get more calls? Whitelisting – This will enable you to get more calls per hour but it is discouraged by Twitter in favor of other techniques like caching, etc.
Take an even closer look at the snapshot below and we will then answer the questions: What are the fields returned and what data types are included?
What we should agree on is that making an API call does not return such clean and formatted data as shown above! You can use a simple script to achieve the same. Either way, assuming you have turned that mess into the above JSON data, you can see several fields: coordinates, Favorited, truncated, created_at, id_str, entities, and many more. The second question is also easy to answer: data types – string, Boolean, objects, arrays, integers etc. Keep looking, you may find something I didn’t mention.
Let us intentionally make an API call that is broken and then see what happens:
There you have it! You get an error message. I didn’t supply the required screen_name or user_id to the user_timeline method. Try it and see what happens! Be curious.
Third question: Path-style vs. Argument-style API calling. Which one is used by Twitter. Twitter uses both! There is a lot to be said here but I will not start a discussion for it today!
Finally: What is RESTful API? I will start by saying this is an advanced concept. In simple terms, it is an API that conforms to the REST constraints and is basically based on a setup where the client sends a request to the server and the server processes the request and returns the result to the client. It uses HTTP protocol. It is also a counterpart to SOAP.
That should do it for today! I hope you found this helpful as you forge a journey through Twitter APIs. If you have any questions, please don’t hesitate to ask. If you have a blog, please leave a link below so I can check it out!
Happy New Year! Peace Be With You!