resource naming is the key
i just read an excellent post by bill deOrha that just *nails* the importance of resource-naming in REST/HTTP programming. it actually brings into focus what i've been trying to do with the exyus framework for the last several months.
this is one of the quotes that really jumped out at me:
The first thing you have to be able to do to program a world of resources is name them. That way they can all have URLs. Then you'll want to map a finite amount of handler code onto requests against them.
it's so simple, really. but most all of my web programming life has *not* been about resources and naming. it's been about functions and classes and scripts - what bill calls the CGI/Stargate approach (read it, you'll see). starting last year, after several attempts to build in-house frameworks that scale (not always so successfully), i determined to get it right. this time i began with a resource-centric model and things began to fall into place. that's why my high-level coding for the blog looks like this:
and why my low-level coding looks like this:
see? resource-naming on the top; uniform interface on the bottom. sure, there's some magic in the middle to support things like handing the methods properly and doing all the cache-work, but the basics are there. i'm not saying it's all peachy under the covers, but i spend most all my time on resources now, not scripts.
btw - i have not established a clean approach to 'lo-REST' - the notion of allowing GET and POST to also model PUT and DELETE. bill's function approach seems like the most appealing, but i think the surrogate URL is closer to the way exyus handles resource naming right now. i'll have to move that one up on my list, i think.
my biggest short-coming right now (REST-wise anyway) is the lack of 'hyper-ness' in my media. now that i'm swearing off session and cookies (new for me), i'll need to start getting serious about hypermedia.