mca blog

having spent several months really digging into HTTP and REST, i find that - more often than not _ i am "thinking in HTTP."

i am putting together a bit longer piece on the notion, but here's the gist. when some comes to me with an information 'task' to do (maintain records online, manage app configurstions, provide a full-blown web UI, etc.) i start thinking like this:

• what are the resources that need to be exposed?
• what are the HTTP methods that need to be supported
• what is the default mime-type of the resources? what are the preferred alternate types?
• can we use Ajax-scripting or do we need to support standard HTML FORM scenarios?
• what are the dependent cache issues (when updating resoruceX, what other resources are now invalid?
• can we use HTTP Auth? (and if not, why?)

in addition to these questions, here are some other assumptions with which i always start:

• we *will* support standard caching models (expiration/validation)
• we *will* support Etags and 304
• we *will* support multiple representations
• we *will* support compression

all this means i *start* by designing a REST-ful web application. and it will take a lot of effort to force me to verr off that course.

hey, it works for me!