Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal)

[Evan Gilbert <[e-mail]>]

On Wed, May 5, 2010 at 10:24 AM, Robert Sayre <[e-mail]> wrote:

> On Wed, May 5, 2010 at 1:06 PM, Evan Gilbert <[e-mail]> wrote:
> >
> >
> > On Wed, May 5, 2010 at 8:28 AM, Eran Hammer-Lahav <[e-mail]>
> > wrote:
> >>
> >> I'll add something to the draft and we'll discuss it. There is enough
> >> consensus on a single JSON response format.
> >
> > Responses that are returned via a browser URL should
> > be application/x-www-form-urlencoded.
>
> I'm not sure I understand here, could you explain in more detail?
>

Sorry, should have been clearer here. Think that any response sent to a
redirect_uri should be form encoded.

The "via a browser" comment was to clarify the goal - it's because this is
sent via HTTP GET to a web server (or other client - JS, installed app -
reading the browser path).

JSON only adds complexity for these cases - the client needs to understand
how to parse URL parameters anyway to get the JSON content, so you're adding
a separate encoding layer.

Non-redirect responses and HTTP POST requests are more interesting.


>
> > These parameters are standard to parse
> > in any HTTP handling library
>
> Any HTTP handling library will claim to support it, but I doubt very
> many non-browser libraries match the HTML5 spec. Don't you find the
> requirements there to be complex relative to JSON?
>

See notes above - all clients need to know how to parse URL parameters
anyway. So we just have to decide on whether we want an additional JSON
requirement.


> > and JSON only adds complexity and external
> > library requirements.
>
> Anything in a browser won't care either way. And won't other HTTP
> clients likely end up talking to a JSON API anyway?
>
> >
> >  But if we support both JSON and application/x-www-form-urlencoded
>
> That is design-by-committee. Let's not do that.
>

All requests and HTTP redirect responses probably need to be HTTP GET
(unless we change the spec significantly) - think this means that we are
supporting form encoding.

For responses, think that sending JSON would be OK. Web serving is often
asymmetrical this way (url params in, HTML out)


> --
>
> Robert Sayre
>
> "I would have written a shorter letter, but I did not have the time."
>