So you want to build a REST application, but you find you have to put all this javascript in the views to construct and POST xml. Nobody knows why HTML 1.1 doesn't have the capability to POST text/xml, but it just doesn't; and if you're waiting for native XForms support in browsers, forget it. So we are stuck with good old application/x-www-form-urlencoded. Learn to love it. It is just another serialization mechanism. We could have whole books and architectures on the topic of "Object-URL Encoded Form Data Mapping." We could have an Apache OUB (Object-UEFD Bridge).

So what is it exactly that we can do with xml, that we cannot do with URL encoded form data? Why get hung up on the type of the resource representation?

So you build your service and it accepts two kinds of representations: xml or UEFD. Either can represent the same resource with equal fidelity. Quibble with me about the hierarchical relationships you can represent in xml. You can represent hiereachies in UEFD using your own patterns (and interoperability really isn't the use case here).