Registration 2.1 - Should request be form-urlencoded or JSON?

[Michael Jones]

Now that we're returning the registration state as JSON, it's pretty inconsistent for the registration request to instead be form-url-encoded. The case can be made for switching to JSON now - especially in light of possibly wanting to convey some structured information at registration time.

I realize that this is a big change, but if we're going to do it, we should do it now.

As a precedent, apparently SCIM requests are JSON, rather than form-url-encoded.

[Michael Jones]

We will continue discussing this until Thursday's call.

[Vladimir Dzhuvinov]

I like this proposal. Clients already have to be capable of dealing with JSON to process the registration responses. Switching to JSON for the requests will make the message exchange symmetrical too.

The ability to go beyond simple key/value pairs is also a plus I think.

[Michael Jones]

The working group decided to make this change

[Nat Sakimura]

Not so sure. For example, PHP cannot get the JSON object form application/json POST in $_POST.

It is OK to have a parameter like "request" that holds JSON. Then, you can get to it from $_POST['request']. However, if you POST the JSON as the POST body, then you would have to call a low level function in the form of:

$file = file_get_contents('php://input');
$x = json_decode($file); 

Not that it is harder, but it is much less known. Many PHP programmers will certainly goes "???".

We need to check what would be the cases for other scripting languages before making the final decision.

[Former user]

It's an increasingly well known pattern that has reasonable support on the server side. For PHP, I was able to find the above example via the top hit on Stack Overflow. In Ruby, it's a matter of something like:

JSON.parse(request.body.read)

depending on the web app framework. On Java/Spring, it's a matter of injecting the entity body as a string and handing it to a parser (Gson in this case):

public String doApi(@RequestBody String jsonString) { JsonObject json = new JsonParser().parse(jsonString).getAsJsonObject();

It's a similar read/parse setup in Node.js as well.

It's true that in all of these cases you don't get to make use of the routing or data binding facilities (though in Spring you can do that for simpler domain objects using a ModelBinding), so you don't get niceities like the $_POST array in PHP handed to you. This is why I don't think it's a good idea at all to switch functionality based on the contents of the JSON object. It should be a domain object only, which is what it would be in this case.

I think that the positives of using JSON from the client's perspective and the overall protocol design far outweigh the slightly increased implementation cost at the server.

[Michael Jones]

Fixed #747 - Changed requests from being form-urlencoded to JSON

→ <<cset 5a7df82c192e>>