For debugging JSON is cleaner than form encoded. I hate faking arrays with space separated list (yes like scopes).
It is the way it is to be consistent with OAuth. I think that should be a separate issue from url templates etc. John On 2013-02-04, at 2:51 PM, Tim Bray <[email protected]> wrote: > From the point of view of developer experience, meh, the degree of difficulty > of generating/parsing JSON & form/url is about the same. > > JSON has the advantage that it forces you to use UTF-8, and is more pleasant > to debug when things get weird. > > For my money, anything that forces anyone to use UTF-8 is A Good Thing. -T > > On Mon, Feb 4, 2013 at 1:46 PM, Mike Jones <[email protected]> > wrote: > I’m not proposing that we boil the ocean. “Diving in with both feet and > define a full RESTful API with all appropriate verbs and CRUD ops” is an > almost sure way to build a complicated spec, most of which isn’t needed, and > to have it take a long time. > > > > Everything in the current OpenID Registration spec is motivated by an actual > use case. Stuff that isn’t isn’t in the spec. That’s nearly true of the > closely-related OAuth Registration spec, with what I believe to be a few > exceptions. (Yes, we should harmonize those differences – hopefully based > upon real use cases.) > > > > I was only proposing that we answer the single question of whether we’re > using the right input format or not. I hope we can keep the discussion to > that topic and not use it to generate a passel of new work items as a side > effect. > > > > -- Mike > > > > From: Richer, Justin P. [mailto:[email protected]] > Sent: Monday, February 04, 2013 1:34 PM > To: Mike Jones > Cc: [email protected] > Subject: Re: [OAUTH-WG] Should registration request be form-urlencoded or > JSON? > > > > For history, the original UMA registration spec from whence this all grew was > JSON-in and JSON-out. It's feeling like this is coming back around. > > > > Pro: > > - more REST-ish (particularly if we use real REST style like URL templates > and verbs) > > - consistent data structures > > - possible use of rich client data structures like lists and sub-objects > > > > Con: > > - unlike the rest of OAuth, which is form-in, JSON-out > > - major change from existing code > > - possible overhead for existing OAuth libraries which haven't had to deal > with JSON from clients > > > > > > > > If we're going to do this, we should dive in with both feet and define a full > RESTful API with all appropriate verbs and CRUD ops, and define it at the > OAuth DynReg level as well. > > > > > > -- Justin > > > > On Feb 4, 2013, at 4:25 PM, Mike Jones <[email protected]> > > wrote: > > > > > Now that we're returning the registration state as JSON, it's pretty > inconsistent for the registration request to instead be form-url-encoded. The > case can be made for switching to JSON now - especially in light of possibly > wanting to convey some structured information at registration time. > > I realize that this is a big change, but if we're going to do it, we should > do it now. > > As a precedent, apparently SCIM requests are JSON, rather than > form-url-encoded. > > > > -- Mike > > > > _______________________________________________ > 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
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
