Digging Into REST

I’ve been on a REST kick for a while now.  It’s been brewing in the back of my head since an interview I did a few months back.

Pete Lacey gives an in depth interview on the topics of REST and WS-* over at InfoQ.  And he points to Dave Megginson’s one line pitch for REST:

With REST, every piece of information has its own URL.

It’s an incredibly powerful concept and it’s empowering for the end user, IMO.

One thing that’s bugged me about REST is that — without having written an explicitly RESTful application — is that using REST over SOAP means much more “plumbing” for web services development.  It was kind of interesting to hear Lacey address this:

There’s scalability, there’s performance, which is primarily influenced by caching, which is built deep into the bones of REST and HTTP, there is simplicity of architecture, not necessarily of development, and this is especially true if you are a client side developer, the point is that we don’t want to hide the network from you and so you actually have to do more work as a RESTful developer of clients that you would simply by spitting out code from a WSDL.

Indeed.  I think this is where I’m a bit torn on REST since the ideal of a resource based view of a system is empowering for end users but today’s tools for working with WSDL allow for much greater producitivity for developers.