Thanks for forwarding that, Mike. I'll paste in my response to Nat's
concern here as well:
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.
-- Justin
On 02/12/2013 02:11 PM, Mike Jones wrote:
FYI, this issue is also being discussed as an OpenID Connect issue at
https://bitbucket.org/openid/connect/issue/747. I think that Nat's
recent comment there bears repeating on this list:
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:
```
#!php
$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.
-- Mike
-----Original Message-----
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Justin Richer
Sent: Monday, February 11, 2013 1:15 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Registration: JSON Encoded Input
Draft -05 of OAuth Dynamic Client Registration [1] switched from a
form-encoded input that had been used by drafts -01 through -04 to a
JSON encoded input that was used originally in -00. Note that all
versions keep JSON-encoded output from all operations.
Pro:
- JSON gives us a rich data structure so that things such as lists,
numbers, nulls, and objects can be represented natively
- Allows for parallelism between the input to the endpoint and
output from the endpoint, reducing possible translation errors between
the two
- JSON specifies UTF8 encoding for all strings, forms may have many
different encodings
- JSON has minimal character escaping required for most strings,
forms require escaping for common characters such as space, slash,
comma, etc.
Con:
- the rest of OAuth is form-in/JSON-out
- nothing else in OAuth requires the Client to create a JSON object,
merely to parse one
- form-in/JSON-out is a very widely established pattern on the web today
- Client information (client_name, client_id, etc.) is conflated
with access information (registration_access_token, _links,
expires_at, etc.) in root level of the same JSON object, leaving the
client to decide what needs to (can?) be sent back to the server for
update operations.
Alternatives include any number of data encoding schemes, including
form (like the old drafts), XML, ASN.1, etc.
-- Justin
[1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
