+1 to what Pat and Justin said.
On Tue, Feb 12, 2013 at 12:59 PM, Justin Richer <jric...@mitre.org> wrote:
> If that's the question, then my proposal is the Content-type is
> "application/json" and the HTTP Entity Body is the JSON document. No form
> posts or parameter names to be had here.
>
> -- Justin
>
>
> On 02/12/2013 02:58 PM, John Bradley wrote:
>
> Some people apparently encode the JSON as the key in a form POST, some
> people do a form POST with a special key and the JSON as the value.
>
> There appear to be a number of theories in the wild. I am not an
> expert I just looked up code examples from several sources stack overflow
> and the like.
>
> We probably need to get input from developers who have experience
> working with different frameworks. I think the differences have to do
> with decoding it at the receiver.
>
> We originally had registration posting JSON but we changed form encoding
> as that worked in all environments. We just need to be sure we are not
> creating problems for people with the change back.
>
>
> John B.
>
> On 2013-02-12, at 4:48 PM, Tim Bray <twb...@google.com> wrote:
>
>
>
> 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
>
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
