On Tue, May 25, 2010 at 6:03 AM, Leah Culver wrote:
> So yeah, I'm against supporting ONLY JSON. I'd be fine if the spec allowed
> for form-encoded, XML or whatever else might become the hot new thing. I'm
> really for leaving it up to the provider. I don't think it's up to OAuth to
> force people
I like your response.
I think application/json and application/xml would be fine without
application/x-www-form-urlencoded. I just thought it made a good lowest common
denominator for serialization which I think aids in making it simple to support
multiple formats.
On May 26, 2010, at 12:19 A
Kris,
> The OAuth endpoint should be able to match the format(s) of the API it
> protects.
I had a quick look at the APIs for 24 services implementing OAuth (v1 or
drafts of v2) as listed on the OAuth wiki.
Of these 24 APIs, the response formats supported were:
* 21 XML
* 19 JSON
* 16 XML and
On Tue, May 25, 2010 at 1:40 AM, Pid wrote:
>
> 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.
Yes, Joseph made a very good argument for JSON.
My only objection is that form-encoded is still use
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
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 al
To me this smells a lot like XML a few years ago... how XML is baked into
XMPP and people thought that HTML should be converted to XML... seemed like
a good idea at the time :D
So yeah, I'm against supporting ONLY JSON. I'd be fine if the spec allowed
for form-encoded, XML or whatever else might b
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 wit
And to add to this, this example shows that encoding is hard, JSON
only solves decoding (in most cases, but not all).
For all direct requests clients still need to encode and without a
library still need to figure what chars must be encoded.
Introducing JSON because dealing with form-encoded is h
This is a bad example. This deals with encoding for the purpose if the
signature base string. Not the same as decoding responses which I doubt is a
problem for Twitter as I think their token values are URL safe.
EHL
On 5/23/10 3:32 PM, "Dick Hardt" wrote:
Frustration devs have with URL encod
Frustration devs have with URL encoding. This is the core motivation to using
JSON as the AS response format.
-- Dick
Begin forwarded message:
> From: Andrew Badera
> Date: May 23, 2010 2:57:44 PM PDT
> To: twitter-development-t...@googlegroups.com
> Cc: oa...@googlegroups.com
> Subject: [oaut
11 matches
Mail list logo
