JSON of a tweet and all, all, all

I’ve revamped my blog today. Some changes are pure cosmetic, others are fundamental whilst visual effect of them is not so much visible. And, of course, everything is pretty valid and standards-compliant (except Google Ads, but that’s another sad story).

First of all, update requests to third-party services like Twitter and Flickr are shifted from server-side RoR libs to clients. That’s the most significant change, I guess. Pages became more static-like. An average response speed increased, and server load dropped dramatically, mostly because of better caching. Resulting pages (which are final flows of HTML code what running server-side scripts send to your web browser) do not contain any frequently changing snippets of information anymore. These pages now contain only placeholders for such snippets. And contents get filled in later in visitor’s web browser with help of Ajax/DHTML scripts.

What I found out dealing with JSON format and public API of different social services is that not all of them are equally useful. Switching from Ruby/XML to Javascript/JSON was very easy for Flickr API. These guys never stop to bring joy to my life - their service if the best among others, API is great, and they’ve just added some new features to Flickr UI. I just love them!

At a first glance Last.fm API is very akin to the one Flickr does use. But unlike Flickr guys (please don’t laugh out too loud) Last.fm does not offer support of JSON format! So I have to use a third-party proxy service to convert provided XML responses to required JSON. Except this migration was not hard.

Twitter API gave me a real headache. Twitter API is BAD! First, it is very restrictive. You can’t get whatever you want through the API calls like you could get just screenscrapping HTML pages and extracting information from there. And I believe some people go this way just to avoid limits and restrictions you face while working with the API. Format of Twitter API responses is bloating. Time and date comes in fancy formats instead of short and useful timestamps. You also get tons of information per each user in a timeline asking only for messages. Imagin what you get in a timeline for one particular user. His profile will be repeated again with every single message! It does not look like API, it’s a damn dump of a Excel spreadsheet. But the most disgusting behaviour is caching. Results are cached! If you, say, use jQuery (like I do), and fire a $.getJSON() call to the API, your request will get a callback name randomly assigned by jQuery. Every next call will have a new unique callback name. But API server will keep returning the first cached response, making your script to fail with error. I had to fallback to more complex $.ajax() call with custom assigned callback name (check sources if you need more details, or drop me a line to email). Finally it works.

And one more rant. The final one. Microsoft Internet Explorer sucks, and should die in hell! Trust me. It has broken (by design) CSS rendering engine, non-standard Javascript Virtual Machine, versions prior 7 even can’t handle transparency of PNG images, and have no clue about multi-tab interface! Do you still use that crap?! If you DO, then take a free advice — go and grab yourself a USEFUL web browser. There are plenty of them: Mozilla Firefox, Google Chrome, Opera, Apple Safari. You don’t have to wait till tomorrow. Do it right now. Are you still reading? Download and install! If your corporate policy limits you to have only IE on your PC, file a complaint! Visit Browse Happy and read it. Search Google for “Why does IE suck” and read it. Learn it for yourself, make your colleagues, you admin, his supervisor, CEO of your company, and even his grandma to know it, too. Be warned and prepared. And make web developers happy!

Published on October 19, 2008 (about 9 years ago)

Article tags: api, browser, json

Comments (0)

No comments.