Christian Heilmann

Posts Tagged ‘REST’

Opera, REST APIs, Module Patterns and generated script nodes

Friday, April 11th, 2008

I just came across an annoying thing in Opera. I love using the Module Pattern for designing my JavaScripts and I love generating script nodes on the fly for REST APIs that give me back JSON. The following example using the twitter API works swimmingly on Firefox and Safari (have to check IE later, but I’d be surprised if it didn’t):

However, if you test this in Opera you get an error:

JavaScript – file://localhost/Applications/MAMP/htdocs/operacallbackfail.html
Inline script thread
name: ReferenceError
message: Statement on line 1: Reference to undefined variable: twitterbadge
Line 1 of linked script[{user : {screen_name : “codepo8”,...08”}]);

It seems like the newly generated script node calls the method of the module before the module has been created. In other words, newly generated script nodes halt the execution of the code that generated them. The following example works across browsers, including Opera:

Not too daunting a fix, but it feels wrong to have to have an extra method and another line calling it.

Try it out for yourself: Opera bug with dynamic script nodes and module pattern

Retrieving tags for the current URL with JavaScript

Monday, February 11th, 2008

If you scroll down the older entries of this blog you’ll see that there is a new feature, namely a box that shows reader tags and a link to

Screenshot of a list of tags with a link to

This is not a WordPress plugin (although it would be easy to make and i’d be amazed if it hadn’t been done) but pure JavaScript. You can also download the script that does this and use the following to embed it in any page you’d like to know the delicious data for:

There is not much magic going on here, I basically souped up the example on the site,minified and embedded Paul Johnson’s implementation of MD5 in JavaScript and created the necessary HTML.

The HTML structure inside the DIV will be a definition list with tags as dd’s and the text as the dt and a paragraph with a link. You can style it by using the #deliciousinfo ID.

I like the outcome and I am always amazed what good tags readers of my stuff come up with. If you want to know, get the src commented version and check the information in there.

Shall I create a WordPress plugin for this?

Edit: if you wondered what the difference to the tagometer is, there isn’t much, I just forgot about it….

Dear API Developers, this is what I would like to have

Wednesday, November 7th, 2007

Jonathan Boutelle of Slideshare reacted to my slideshare show widget and liked how I hacked around the API by re-using the RSS feed. He now asked in the comments what I’d like to see from an API. Well, here goes:

  1. Allow for “hackable” URLs, with definition of the output. Flickr and are good examples, especially the option of defining a callback for the JSON: gets me a JSON data wrapped in a Delicious object, gets me the raw JSON data and wraps it in a function call to foo(). This rocks! The same goes for defining the output as the last parameter. Flickr does that well – for JSON, for RSS, for LOLCAT
  2. make sure that the JSON output is easy to use and does not have any annoying bits (encoded HTML or namespaced attributes – the description property in the flickr JSON to me is pointless weight for example)
  3. make the URL as logical as possible, I don’t like to have to use the user ID in flickr for example when the readable user name would be easier to do.
  4. it’d be great if you could send a unique ID as a parameter as that would allow you to match returned data to calls (as both dynamically created script nodes and Ajax calls may return in any order)

However, all of this does not replace the real API, which should

  1. allow me to define only the data bits that I need (and cut down to the smallest possible feed – no twitter, 150kb JSON is not good!)
  2. give me extras when I go through a developer ID. How about offering me free stats (even as an own API) when I build a widget that uses my ID - we do this now to throttle usage anyways. In a second phase this could also be used for a revenue sharing program.
  3. offer things like enforced authentication (you know the photos you don’t want to show your mother)
  4. allow for local caching methods (deliver the data gzipped for example)
  5. allow me access to things that the open REST calls don’t (my sets, my favourites, my contacts, my profile settings)
  6. be read and write – I want to build widgets that allow data entry from my blog to your systems, without leaving it.

Anything else?