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 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
