If that works for you, awesome.<p><i>HTTP and REST give you several ways to make requests (PUT vs. POST? Fall back on POST for clients that don't support PUT? How?)</i><p>PUT is used for update operations and POST generally for create. Your library will abstract away the "client doesn't support sending PUT" so you don't deal with it. Same way XML-RPC libs abstract away the ugly portions of XML-RPC.<p><i>several ways to specify parameters (URL path fragments, query strings, headers, or POST data?)</i><p>Yes, there's more than one way to do that. Generally a service's documentation tells you what to do, so I'm not seeing the issue, but I concede that someone might find fault with that.<p><i>and a set of standard errors that you do not control and which are not used consistently</i><p>Whereas XML-RPC gives nothing, and everything is re-invented every time. Again, if that's a better solution for you, awesome, but for me the "some people use HTTP status codes to mean different things" isn't a reason to throw the whole thing out.