Most of our POST end points currently accept multipart/form-data / application/x-www-form-urlencoded or JSON. However, only JSON can represent nested structures, which is occasionally useful to avoid very repetitive names.
Idea: Reuse dot notation from TOML
Tom's Obvious, Minimal Language (TOML) maps nested object structures to dotted path syntax, and creates implied objects on demand. We could copy this idea to represent nested structures in POST keys.
Examples:
JSON:
{
"foo" : {
"bar": "one",
"baz": "two"
},
"quux", "boooz"
}POST data:
foo.bar: one foo.baz: two quux: booz
Using this scheme to support overriding HTTP method or headers
We could consider leveraging this scheme to better and generally support HTML form interaction with REST APIs. HTML forms still don't support methods other than GET or POST (without JavaScript) or the specification of request headers, which complicates the creation of form front-ends for REST APIs. Some REST APIs offer ad-hoc header-based work-arounds for the method issue, but there doesn't seem to be anything general. As a result, APIs that need to be usable from HTML forms come up with custom semantics / POST keys, and generally can't use the full set of HTTP methods and headers. To avoid this, we could consider defining a general _http. override object like this:
_http.method: put _http.headers.if-match: "679786764/581593fe-54d0-11e5-96a3-1b0c6675c2e8"
In the service processing the POST request (RESTBase, for example), this could be pulled out of the POST body in a general pre-processing pass on a POST request, before any routing or security checking has taken place. To avoid abuse, we could restrict this to a small white-list of methods and headers.
See also T101501#1614873 for the original discussion of this issue.