Agreed that REST purity may come at a cost that's too high. On the other hand, it's a useful exercise to imagine how much more benefit could potentially be gotten "for free" if we look at it through a pure-REST lens, not just with what's already been specified but the whole picture.
If what you're registering is a client descriptor, then creating a new one, updating an existing one, deleting, and even patching could come for free if something like the following framework is used: http://tools.ietf.org/html/draft-pbryan-http-json-resource-03 With standard libraries possibly floating around to support this framework (I think Paul B wrote one; maybe he open-sourced it?), it starts to become a lot cheaper to support client registration on both sides of the interaction. Eve On 23 Jan 2013, at 8:34 AM, Sergey Beryozkin <sberyoz...@gmail.com> wrote: > On 23/01/13 15:47, Justin Richer wrote: >> Which brings up an interesting question for the Registration doc: right >> now, it's set up as a single endpoint with three operations. We could >> instead define three endpoints for the different operations. >> >> I've not been keen to make that deep of a cutting change to it, but it >> would certainly be cleaner and more RESTful API design. What do others >> think? >> > IMHO the purity should be balanced against the practicality/simplicity > of the implementation. > Talking about 3 endpoints at the spec level may be treated as the exact > requirement to have 3 separate application endpoints for the single type > of activity, the registration. Can the spec be re-worded such that > "resources" are used instead of endpoints or similar, example, "resource > available at /a will support the following, at /b - something else", or > may be something similar, thus it will read better too from the design > point of view, and let implementers to use 1 endpoint or 3 ones, > whichever way they prefer it > > Thanks, Sergey > >> -- Justin >> >> >> On 01/22/2013 08:05 PM, Nat Sakimura wrote: >>> "Action" goes against REST principle. >>> I do not think it is a good idea. >>> >>> =nat via iPhone >>> >>> Jan 23, 2013 4:00、Justin Richer<jric...@mitre.org> のメッセージ: >>> >>>> (CC'ing the working group) >>>> >>>> I'm not sure what the "action/operation" flag would accomplish. The idea >>>> behind having different endpoints in OAuth is that they each do different >>>> kinds of things. The only "action/operation" that I had envisioned for the >>>> introspection endpoint is introspection itself: "I have a token, what does >>>> it mean?" >>>> >>>> Note that client_id and client_secret *can* already be used at this >>>> endpoint if the server supports that as part of their client credentials >>>> setup. The examples use HTTP Basic with client id and secret right now. >>>> Basically, the client can authenticate however it wants, including any of >>>> the methods that OAuth2 allows on the token endpoint. It could also >>>> authenticate with an access token. At least, that's the intent of the >>>> introspection draft -- if that's unclear, I'd be happy to accept suggested >>>> changes to clarify this text. >>>> >>>> -- Justin >>>> >>>> On 01/22/2013 01:00 PM, Shiu Fun Poon wrote: >>>>> Justin, >>>>> >>>>> This spec is looking good.. >>>>> >>>>> One thing I would like to recommend is to add "action"/"operation" to the >>>>> request. (and potentially add client_id and client_secret) >>>>> >>>>> So the request will be like : >>>>> token REQUIRED >>>>> operation (wording to be determine) OPTIONAL inquire (default) | revoke >>>>> ... >>>>> resource_id OPTIONAL >>>>> client_id OPTIONAL >>>>> client_secret OPTIONAL >>>>> >>>>> And for the OAuth client information, it should be an optional parameter >>>>> (in case it is a public client or client is authenticated with SSL mutual >>>>> authentication). >>>>> >>>>> Please consider. >>>>> >>>>> ShiuFun > Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
