On Tue, Feb 12, 2013 at 11:44 AM, John Bradley <ve7...@ve7jtb.com> wrote:
> Nat and I hashed out the pro's and cons of JSON requests.
>
> If we POST or PUT a JSON object we need to be specific as there rare
> several ways to do it that may work better or worse depending on the
> receiver.
> This needs to be looked over and one picked.
>
Hm? Not following on “several ways”, I’d have thought that POSTing JSON is
just POSTing JSON, must be missing something. -T
>
> In the other thread about the server returning the update URI and being
> able to encode the client in that if it needs to takes care of Servers that
> need that info in query parameters or the path to do the routing.
>
> The use of structure can be used to enhance readability and parsing of the
> input, and output.
>
> However we need to temper our urge to apply structure to everything.
>
> IT needs to be applied carefully otherwise we start looking like crazies.
>
> If we do it cautiously I am in favour of JSON as input.
>
> John B.
>
> On 2013-02-12, at 4:32 PM, Justin Richer <jric...@mitre.org> wrote:
>
> 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<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****
>
> https://www.ietf.org/mailman/listinfo/oauth****
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
