+1 for always including the client_id As John pointed out, there could be different entities updating client data. Then one has to distinguish the resource and the credential.
Am 12.02.2013 um 02:51 schrieb John Bradley <ve7...@ve7jtb.com>: > I would always include the client_id on update. > > I think it is also us full to have other tokens used at the update endpoint. > I can see the master token used to update all the clients it has registered > as part of API management. > Relying on the registration_access_token is probably a design that will cause > trouble down the road. > > I think GET and POST are relatively clear. I don't know about expelling PUT > to developers. I think POST with a client_id to a (separate discussion) > update_uri works without restricting it to PUT. > > I think DELETE needs to be better understood. I think a status that can be > set for client lifecycle is better than letting a client delete a entry. > In some cases there will be more than one instance of a client and letting > them know they have been turned off for a reason is better than making there > registration disappear. > So for the moment I would levee out DELETE. > > John B. > > On 2013-02-11, at 6:14 PM, Justin Richer <jric...@mitre.org> wrote: > >> Draft -05 of OAuth Dynamic Client Registration [1] defines several >> operations that the client can take on its behalf as part of the >> registration process. These boil down to the basic CRUD operations that you >> find in many APIs: Create, Read, Update, Delete. Draft -00 defined only the >> "Create" operation, draft -01 through -04 added the "Update" operation, >> switched using the "operation=" parameter. >> >> Following several suggestions to do so on the list, the -05 draft defines >> these operations in terms of a RESTful API for the client. Namely: >> >> - HTTP POST to registration endpoint => Create (register) a new client >> - HTTP PUT to update endpoint (with registration_access_token) => Update the >> registered information for this client >> - HTTP GET to update endpoint (with registration_access_token) => read the >> registered information for this client >> - HTTP DELETE to update endpoint (with registration_access_token) => Delete >> (unregister/de-provision) this client >> >> The two main issues at stake here are: the addition of the READ and DELETE >> methods, and the use of HTTP verbs following a RESTful design philosophy. >> >> Pro: >> - RESTful APIs (with HTTP verbs to differentiate functionality) are the norm >> today >> - Full lifecycle management is common and is going to be expected by many >> users of this protocol in the wild >> >> Cons: >> - Update semantics are still under debate (full replace? patch?) >> - Somewhat increased complexity on the server to support all operations >> - Client has to understand all HTTP verbs for full access (though plain >> registration is just POST) >> >> >> Alternatives include using an operational switch parameter (like the old >> drafts), defining separate endpoints for every action, or doing all >> operations on a single endpoint using verbs to switch. >> >> -- Justin >> >> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05 >> _______________________________________________ >> 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
