mca blog

found this today. nice write-up on how REST can be used to handle reliable messages over an unreliable network (HTTP). by separating "state" (from the server) and "intent" (from the client), benjamin describes and interesting approach to the problem.

this paragraph jumps out at me:

The distinction between overlapping resources that make intent difficult to isolate and those that are merely normal side-effects is in the methods those additional resources support. It is only intent we should be disambiguating. We should be attempting to ensure that every intent is only conveyed through one resource: That multiple resources don't carry overlapping intents by their PUT requests. It is still ok that resources without PUT implementations overlap.

i need to read it again (few times[g]) to make sure, but i think he also describes some fairly strong constraints in the *client* to sort some of this out. might not be a good idea, but i need to dig into it a bit more.