mca blog

i've been mulling the whole 'cookies and state' thing as regards to REST-ful (and cache-able) web apps. i've kinda come to this. state is not really a big issue when it comes to a well-designed web app. ok, you might need a shopping cart or some other kind of 'bucket' in which to hold user-based data. but that can live as a resource on the server. the user's collection. and that resource can be accessible via AJAX or JSON or even pushed back to the client in one or more hidden inputs in an HTML FORM. and if you buy into that notion (user-based data lives on the server as a resource and can be accessed both via AJAX and HTML FORM) then cookies are just not important.

ok, you need to identify the user. but that would be through authentication, right? sure you *could* create data buckets without a login (by generating a random session id and passing that via cookie), but is that really what we want to do?

and, yes, HTTP Auth is kinda ugly for browser apps right now (little control over the dialog box and some issues with timeouts, etc.). but is it really worth it to circumvent all that for form-based logins that are not HTTP (and cache) friendly? i don't think so (anymore).

so the deal is this:

you want user-specific data?

you gotta log in via HTTP Auth

you want to store data on the server?

you gotta define a resource object to hold the data (a general name-value pair would be acceptable) and then manage that resource on the server like any other.

you wanna access this resource from the client

you gotta do it like any other resource - AJAX/JSON or via FORM inputs for HTML-only clients

the technology is all there to do this very efficiently and do it without adding strain on the server, the client, or the network. no wonder there is a dearth of meaningful stuff written on this topic. it boils down to pretty simple stuff. and stuff that's been around for a long time.

now i just gotta get my head around designing and implementing web apps this way. time to step up!