mca blog

this is a very thoughtful post from Bill de hÓra. it covers the notion of using POST to for partial updates to a resource instead of using PUT. this is a long-running issue w/ REST-types. most (not all) folks 'steeped' in the REST-world think POST for modifications is a bad smell. most who grew up coding in HTML think GET and POST are the only reasonable options.

here's a snippet from Bill's post that sez it pretty clearly:

...I'm not sure we in the pro-REST community have a good general answer or design pattern for partially updating a resource. Until we do, I predict people will tend drop down to using forms posting as it's the easiest thing to do with deployed client libraries and web frameworks. That or define some other specialised media type for partial updates.

partial update is the problem

IMO, neither HTTP methods nor HTML FORMS are the problem. partial updates are the culprit.

once you start introducing partial updates, you open yourself for caching problems. doing partial updates means all cached copies of the original resource are now invalid. this is fine if you have a large-grained caching model that means you don't care if some representations are out-of-sync for a while (minutes? hours? days?). but if you need to keep your cached copies clean (i.e. some highly fluid resource), then it's important to signal to caching servers that the resource has been updated. that means the machine accepting partial updates now has the responsibility to invalidate both the partially updated resource *and* the original resource. expose enough of these partial updates and you can have a rats nest of invalidation to commit for each little change of a single element.

by my way of thinking, it's better to keep your edits large-grained and avoid trying to keep track of which resource(s) each partial update invalidates.