+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