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]<mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
