Once again, I want to plea the case for keeping the response simple key/value
string pairs so it is trivial to serialize to multiple formats. The OAuth
endpoint should be able to match the format(s) of the API it protects.
Given this simple response payload, the spec can generically describe how to
serialize the string key/value pairs to application/x-www-form-urlencoded,
application/json and application/xml with other formats added through
extensions.
Values that are lists can simply be a delimited string, with the delimiter
either a character that cannot be in the value (like space delimited urls) or
use a simple escaping mechanism described by the spec. Integers can be spec'd
as such and not rely on format spec. I know, this means in JSON
{"expires_in":"3600"} which gives people a rash but helps make it trivial to
decouple format.
String encoding should be specified by the charset parameter of the
Content-Type header of the response. The client could indicate supported
charsets through Accept-Charset in the request. Likely this should match how it
is handled in the protected APIs. Anyway, let me digress a little, which
responses from an OAuth endpoint are even likely to run into any problems with
encoding -- what needs more than ASCII? Even if a bearer token is in JSON you
could still use \u escapes on a UTF8 encoded JSON to reduce it to ASCII.
Some of the arguments for JSON as the only format remind me of an infomercial
where they make a basic kitchen implement look harder to use than it is, to
exaggerate the need of their handy dandy slicer dicer tool.
No, there aren't a lot of libraries that do form decoding on the client side
(if it is a language that is only typically used on the client side, is this
anything but JavaScript or ActionScript?) but I can't think of any that do not
have decoding for percent encoding (which isn't hard anyway) and the rest is
trivial to parse.
The headaches in OAuth 1.0 came from the signature base string's use of percent
encoding which is a separate issue from using application/x-www-form-urlencoded
as a response type.
Making the OAuth endpoint any one format (unless that response type is truly
trivial to parse without 3rd party libraries) renders an APIs support of
multiple formats (which seems quite popular) pointless.
On May 25, 2010, at 1:40 AM, Pid wrote:
> On 25/05/2010 01:52, Dick Hardt wrote:
>>
>> On 2010-05-24, at 4:55 PM, Marius Scurtescu wrote:
>>
>>> And to add to this, this example shows that encoding is hard, JSON
>>> only solves decoding (in most cases, but not all).
>>
>> JSON solves encoding and decoding with the same library.
>>
>>>
>>> For all direct requests clients still need to encode and without a
>>> library still need to figure what chars must be encoded.
>>
>> You argued this point numerous times at the in-person meeting. Clients are
>> used to encoding and creating requests to servers. That is what they do.
>> There are many simple ways of doing this.
>>
>> Clients in general do NOT decode forms data, that is done by servers, and is
>> built into server frameworks.
>
> If one was feeling mischievous, one could argue that an implementer only
> needs to find or create a library for the client side, rather than both
> - like JSON.
>
>
>>> Introducing JSON because dealing with form-encoded is hard does not
>>> make much sense. As discussions last week showed (and earlier on this
>>> list), with JSON there is also the perception that it is easy to do by
>>> hand and that no escaping is needed. IMO that will lead to way more
>>> problems.
>>
>> Libraries exit for encoding and decoding JSON. They are really easy to use.
>> There is asymmetry in the forms data. Servers typically decode, and clients
>> typically encode.
>
> I really don't think this is a reasonable argument in favour of JSON.
> It's somewhat confusing to argue in favour of using an external library
> on one hand, but not the other.
>
>
> The best summary of the arguments in favour of JSON was by Joseph Smarr
> in response to my previous inquiry, which hasn't been superseded, I think.
>
> However, IMO JSON is yet to be demonstrated as the better solution.
>
>
> p
>
>
>
>> _______________________________________________
>> OAuth mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
