Fragments of a wanderer- Part II

Ever so tired you couldn't stay awake, but then go to bed only to end up staring at the ceiling all night long? Have I just screwed up my biological clock... or am I really losing it?!?

Ever wonder why we hear birds chirping at 2:30 n the morning? Have we messed up their biological clocks with all the artificial lighting?!?

Taking the stack for granted

I recently started off on a .NET engagement (my first actually) and I'm already p!ss*d 0ff !!!

It amazed me no end how much of the software on my computer .NET 3.0 and ASP.NET 2.0 simply assumed or installed without even checking too see if I really wanted to be tied in to it.

For instance, ASP.NET automatically assumed that all my apps would be floated on IIS 5.0. Interestingly enough, Visual Studio.NET 2008 also made the same assumption and required me to have a well configured instance of IIS up and running every time I OPEN my project! So now, I just leave my IIS instance up and running all the time; in fact, just like almost every other ASP dev would have to, I have the IIS service set up to start automatically on boot. :(

And when it came to security, every one just assumed that we were using Windows Domain User Authentication. ASP.NET even has its own sweet little group of users that run the sites and impersonate as users on them. You just grant them access and shazam! you're good to go.
Except now you're stuck with that group and any fine grained access control is going to entail some serious Active Directory management... that I'm not at all keen on!

What all this points at is how Microsoft seems to want to lock us into their stack. Given that there aren't really any other viable platforms to host .NET apps, we don't really have much of a choice in the components; but even when the options do come in, these assumed dependencies will raise the barrier to entry for those options to unsurmountable levels. So we're going to be stuck with M$, for ever!

I guess some people are just never going to get it.

Putting REST to rest

... or Why Implied Interfaces make for poor Implementations.

Representational state transfer (REST) is a style of software architecture for distributed hypermedia systems such as the World Wide Web.

- from Wikipedia

The term REST along with the principles it implies (or 'should' imply!) were put down in a doctoral disseration by Roy Fielding.

Actually IMHO, REST is just SOA and WS wrapped in a layer of OOP with just a generic Resource entity at the application layer. Even then, you kinda get to roll your own with everything- serialization, interaction, responses, validation...

Well... OK, I may have over-genericised that. But, the funny thing is, that's the funny thing about REST! It is very generic.

Even the primary 'Resource' definition is vague; the interface is almost completely implied-

• POSTing to a URL creates a new resource (POSTing what?!)
• I GET a resource referenceable at a given URL provided an id, otherwise... I get all resources at that URL (?); unless, of course, it is a singleton resource, in which case I get the singleton instance. :S
• PUTting causes edits, although POSTs may behave in the same manner
• HEADs can be used to detect the presence of a resource, while DELETEs... delete!^[1]
• And I'm not even sure if OPTION and TRACE are relevant

And that's just REST over HTTP! Wait!! Is there any other REST?!? Well actually REST is a meta-architecture, it's protocol-agnostic. It's supposed to work for all hypermedia- so we should be able to do it over HTTP, FTP, SMTP, SNMP(?)...

What is hypermedia? Media hopped up on too much sugar?!? Well, the Oxford Dictionary defines it as

an extension to hypertext providing multimedia facilities, such as sound and video.

I don't know about you, but my brains just about ready to explode.

But wait, it gets better. Some people liked the REST over HTTP idea so much that they forked their own flavour. So Fielding has Vanilla, while (these guys) have Extra Fudge! (all puns intended) It's called Web-Friendly services- services that behave reeeeally well with HTTP. Basically services that behave like web pages. Whoa! I'm getting asmx flashbacks!!! So I'm gonna shut up about that now.

Then there's the Hypermedia As The Engine Of State Transfer people^[2]. These guys really love the URL. To them the body is whatever it's gonna be! Now it's an XML document, now it could be a HTML FORM, then it could be a JSON object or, maybe, a hCard. I'm sorry, but I can't comprehend this comically 'uniform' interface where your interaction modes are implied, reference end-points are overloaded and results are undefined, or implied, or... did you say they're documented somewhere?

The question I arrive at, then, is- why do we want to be RESTful or Web-Friendly? The loudest argument I hear is that the infrastructure has has already been laid; web servers and proxies with caching, DNS servers, IP routers with path optimization algorithms, the whole kahuna! Think of all the automatic performance gains arising from all that caching! All the more reason to stick more stuff into the URL and fill up those HTTP parameters you never thought to use until now! You just ride the wave!

Hmm... it would seem that REST intends to counter the end-to-end principle by allowing for intelligence (optimizations) at the nodes, but that's a little too debatable; so <sidestep />.

But stepping back a bit, lem'me get this right. We're trying to fit an application protocol directly over a document delivery infrastructure? You've gotta be kiddin' me! I'm not saying this can't be done, just not without a cost- TANSTAFL. Just think about all the time you're going to spend on deciding and negotiating a wire format, and corresponding responses. And that's just one wire format. REST talks of 'representations', a resource could have more than one wire format! I don't know about you, but I've had trouble getting people to understand one wire format right, and now you're telling me they're gonna want to send 'resources' in XML, JSON, YAML, HTML, delimited strings, multi-fixed and EBCIDIC? Over my dead body!!!

Plus, the wireformats are completely arbitrary. Every resource implementer gets to pich their own. So you end up having to 'understand' the specific wire format of every resource you interact with. And by 'understand' they mean RTFM. So much for convention over configuration. Just too much Knowledge in head vs Knowledge in world.

Actually, the wire format is where it gets really funny. XML just had the attribute-element dilemma, REST elevates it to the payload-parameter dilemma! Most Web-Friendly service makers get away without a body to the requests, they just stick a bunch of 'required' HTTP parameters on to the resource URL. So much for 'representation' of 'state', we're back to representation of output. Why does this remind me so much of WS?

I think REST could find application in internal applications where the domain model is well defined, where resources and their interactions are well defined. But I'd still be skeptical because I tried that once at work and we kinda crashed and burned. The biggest brick wall we hit was latency. Given the 'resource' unicycle that REST provided and the specific verbs HTTP provided made our resource interactions multi-stage, especially since REST is stateless. When updating a resource, I wanted to GET a representation of the current state of the resource, modify it and PUT the modified state representation back into its place. But others on the team felt that adhering to those principles added unnecessary communication overheads and chose to add interaction verbs, which was conveniently provided for by ActiveResource. Oh, and that's just when we were not arguing about the wore formats.

Honestly, if you ask me, the only reason REST wont go down the tube like Hailstorm is because it's community driven, not governed and controlled by a megalomaniac. Everyone gets to roll their own and even fork while still calling it RESTful. But even if it does last, I think it's only going to be a buzzword that we'll all have a good laugh about in a few years-

Raj: Hey Saager, we're building this new service for so-and-so and it's accessible via, get this... RESTful resources! :D
Me : Wait, are you sure they're not Web-UNfriendly?!? =D

1 the DELETE's about the most logical thing I got so far! :P
2 sorry Dave, your post is the only one I could directly reference to HATEOS