Just POST the JSON as the HTTP payload with mime-type application/json:
$ curl -v -H "Content-Type: application/json" -X POST -d '{"Hello": "World"}'
http://requestb.in/19qit4u1
* About to connect() to requestb.in port 80 (#0)
* Trying 107.20.236.186... connected
* Connected to requestb.in (107.20.236.186) port 80 (#0)
> POST /19qit4u1 HTTP/1.1
> User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7
> OpenSSL/0.9.8r zlib/1.2.3
> Host: requestb.in
> Accept: */*
> Content-Type: application/json
> Content-Length: 18
>
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Date: Tue, 12 Feb 2013 20:03:39 GMT
< Content-Length: 3
< Connection: keep-alive
<
ok
* Connection #0 to host requestb.in left intact
* Closing connection #0
Cheers,
Pat
--
Pat Patterson | Principal Developer Evangelist | 408-849-4681 |
http://about.me/patpatterson
On Feb 12, 2013, at 11:58 AM, 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
<[email protected]<mailto:[email protected]>> wrote:
On Tue, Feb 12, 2013 at 11:44 AM, John Bradley
<[email protected]<mailto:[email protected]>> 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
<[email protected]<mailto:[email protected]>> 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: [email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Justin Richer
Sent: Monday, February 11, 2013 1:15 PM
To: [email protected]<mailto:[email protected]>
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
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
