K. Ari Krupnikov wrote:

If the scope of the potential side effects is small and well-defined, you might be able to reduce everything to a single exchange: get all of the potentially-affected state to the client in a single XML document (or collection of XML documents), allow the client to make changes locally until satisfied, then post the modified state back to the server. Since modifications live on the client side until committed, there is no need to come up with any separate URL scheme.

This approach would work for, say, a movie database, where the user might check out a full movie description to change the director's name, then check the entire description in again. It might not work so well for, say, a geographical database, where a modification to a shoreline may also require corrections to landuse data, roads and railroads, and so on, in no easily-predictable way.

It is entirely possibly that your project is one in the second category, but I wouldn't give up on the simpler approach until it were proven inadequate. Stupid-and-easy usually wins: moving 50K of XML each way once can be much more efficient than many 100 byte transactions.