mca blog

i've been digging quite a bit into the "hypermedia as the engine of application state (HATEOAS)" aspect of REST-ful implementations. to that end, i've been working to define valid media-types for XML and JSON that properly support "hypermedia" (links and forms in the document). along the way, it dawned on me that there is a fundamental aspect to HTTP conversations that i've not clearly seen before:

HTTP is all about state engines

the HTTP server is a state engine.
the Web browser is a state engine.
so...

when i decide to implement a desktop application that uses HTTP to communicate with a server, that desktop application should be a state engine, too.

this impacts the design/implementation of the client. and it impacts the design/implementation of the resources passed between client and server. if you define resources that are sent from the server to the client that contain well-understood hypermedia, the client can respond accordingly. it also means you can update the server resources and expose new hypermedia to the client without requiring a new version of the client.

hypermedia *is* the engine of application state!