While we're on the subject of breaking changes, I'm now seeing some merit in replacing the fieldnames parameter with a field-specifying prefix.
Currently when you want to set a non-body field, you introduce the field name in the fieldnames parameter and then specify its value in another parameter, like so:
The alternative would be to to signal the fields f1, f2, and f3 by a field prefix, like so:
Because the f prefix says "this is a field", there's no need for the fieldnames parameter.
This isn't an Earth-shattering improvement, but there are three things I like about it:
1. The URLs are shorter
2. If you rename a field (e.g. rename f3 to g3), you can't accidentally half-update the URL in the client code, like this:
3. Currently there are certain reserved words (e.g. "fieldnames", "commit") that you can't use, because they have special meaning to the handler. But with this change they become legitimate field names. For example, maybe I want each of my documents to have a "commit" field that describes who made the most recent relevant commit in a version control system.
I can't think of any downsides right now, other than breaking people's code. (I do admit that is a downside.)