mca blog

after spending the last week working on my XmlFileHandler module to add proper support for PUT w/ ETag checking along with additional regex support to allow (theoretically) unlimited nesting of resource definitions for URIs, it has started to dawn on me that the resource focus is what really counts.

i started my REST-ian framework by writing a SQL-store backend and adding support for the HTTP verbs in front of that. worked well. i skipped a lot of the caching and 'advanced' things like Etags and kept PUT as an 'update-only' method. but things changed when i decided to implement a file-based handler.

i realized that unlimited URI space meant i needed to be able to create and support nested resources (/posts/{pid}/comments/{cid}/replies/{rid}). i also realized that i needed to implement support for create on PUT (meaning solving the lost update problem, etc.). and getting this right for a file-based handler was easier to see (in my mind) than for a relational-db handler. i could just *see* how resources were related (by looking at the file structure on disk) and how important it was to support resource names when creating them (using PUT).

i also learned how to leverage HEAD to check for existing resources, how to manipulate HTTP Headers to check for ETags and modified dates, and how to start 'pipelining' within the framework to do more sophisticated tasks such as emitting multiple requests on the server to start executing simple workflow.

so it makes more sense to me now. more sense because my brain was able to focus directly on the *resource* (re:file on disk) and how to use the HTTP verb set and Headers to get (just about any kind of) work done. it's the resource, stupid!