you semi-lost me at "WSGI middleware that explodes out the requests, turning that example into two WSGI requests." does that mean at the HTTP level, theres just one request, then the middleware creates multiple WSGI requests in-process ? since when I read this, the main thing jumping out at me is "you have to make 4 separate requests to set 4 different attributes, hows that going to work for 10 users at once ?". i.e. yes the transaction-ness is one issue, but also just plain memory/time overhead of all those connections.
Generally REST is better optimized for reads than writes anyway. In the particular situation I'm in neither performance is terribly important -- it's just a configuration API, not part of the regular functionality. 4 GETs could be optimized just with Keep-Alive, assuming going up and down the backend stack is fast enough. It depends on the application of course, but multiple requests aren't necessarily a problem. And really while I stuffed a bunch of configuration in one piece of code (WSGI middleware actually), it's really covering about 3 different use cases, and potentially all of those could be handled separately, and then it really should be multiple requests. (Unless I automatically aggregate them somehow, which is what I'm considering here.)
also, while the whole PUT /my/attribute thing is pretty cool, i must admit my instinct to set 10 attributes at once would be just, POST /my/object .... attr1=val1&attr2=val2&... is that so terrible ?
Sure, you could do it that way, though each of those attributes is at least moderately complicated (generally each is a JSON document). It's not that different from what I propose, actually, except what I discuss can be understood by an intermediary. Well... actually I can't decide on the difference between multipart/mixed and multipart/form-data, which itself is used in HTML forms already. So it's not necessarily even that different from a POST, just adding in some path and method headers.