| HN Mirror

> My fear is we're redefining WSDL in JSON's clothing.

Absolutely not. There is a 'WSDL in REST' called WADL, and it's _terrible_. WSDL/WADL is like static typing: you have to declare everything up front, it's super rigid, and prone to breaking. Hypermedia is like dynamic typing: it all happens late bound, it's flexible, and open to change.

> the code to actually do something with it is, and that's where my spidey sense starts tingling

Here's one of the simplest examples I can show you: the 'hypermedia proxy pattern':

https://gist.github.com/3172911

Here's the core of the code: https://gist.github.com/3172911#file-client-rb-L27-L37

This says "parse the links out and save them. When I try to load a name, if it doesn't exist, go fetch it from the link pointed to by 'self.'

This allows you to change the client behavior by modifying the server: by compressing or expanding responses, the client makes more or less requests without changing its code. Jon Moore demonstrates this with Java, Python, and XHTML here: https://vimeo.com/20781278 I demo'd this exact example at the end of my talk here: http://oredev.org/2012/sessions/designing-hypermedia-apis

Did you see my Shoes Microblogging example for ALPS? https://gist.github.com/2187514

The meat of it is here: https://gist.github.com/2187514#file-microblog_client-rb-L33... This isn't the best factored example, but I wanted to show a tiny client: this is a GUI program that can read from any ALPS compliant server (like http://rstat.us/) and read/post new status updates.

------------------------------------------------------------

What I will say is this: I don't feel it's _harder_, but I do feel it's _different_. Just like if you try to write Java in Ruby, if you try to write hypermedia APIs like another style, it will feel hard and foreign. I think it's easier to implement a number of clients over time for a hypermedia service, than it is to write a bunch of clients over time for a "Rails REST" one.