Links

Patrick Mueller elsewhere: muellerware.org, twitter.com/pmuellr

Tuesday, November 20, 2007

rest won, what now?

So, REST won, what now?

Design tools.

Ugh, you're saying! We don't need no stinkin' tools! We're tough men and women, we use text!

Yeah, well, even fuzzy seemed to like these drawrings (sic; remembering Simon from SNL). And I have to admit, there's certainly some value in being able to visualize services like this.

The images though, are quite crude. You'd see much better stuff coming out of something like Rational Solution Architect. Can it model REST services like this? Would be nice.

But even just visualizing these isn't quite enough. I might want to actually develop my services in a tool like this. Look at the pictures again; not much there; a URL template, an HTTP verb, a mime-type indicating input and output data. That's just meta-data, stuff that you could easily extract from a service definition. We don't need to go very deep to be able to reason about that kind of stuff.

It's easy to imagine even being able to go bi-directional on it. Start by drawing your services, implement the code, and then iterate, modifying your service definitions and having a visual tool pick up the changes. Easy pickens.

Let's take it a step further; imagine having your REST services available in a palette that you can connect up to some kind of user interface builder. How hard is that? Easy to imagine anyway.

And that's where we need to get. For all the grumbling and debates over the complexity of implementing mutating REST services, that's actually the easy part. Building a user interface around usage of those services is the hard part. Building UIs has actually gotten harder over the years, since we have much more flexible user interface capabilities at hand. Built a spiffy web-based user interface in HTML recently? - not easy. Integrating a lot of RESTy service invocations into this mix just adds even more complexity. I think we can make things a little easier.

Tools like TIBCO General Interface point the way to how us mortals will be building web-based user interfaces in the future. The main problem with TIBCO GI is that even it's too complicated; folks would be willing to live with something less rich, yielding a cruftier user interface for their application, if you gave them something an order of a magnitude easier to use. It's coming. It needs to be coming.

Until we're there, it's time to start thinking about what we can do to make life easier later. Basically, we need to start figuring out how to describe our services and data in a machine-readable way. If I was dumb, I'd bring up the work 'schema', but ... I won't. Instead, I'll bring up the trendy, happy word 'microformats'. Documenting our web services in hand-crafted HTML, or Visio diagrams isn't enough.