DELETE is removing the record not resetting it to defaults. They are quite diffrent.
I want to agree on what the expected behaviour of DELETE is. I think we have agreement on PUT and POST. The general not in that a client can DELETE it's record is a implication I don't like. I think that is for the server to decide and if it is not actually deleting it then DELETE is the wrong verb to use. John B. On 2013-02-13, at 3:31 PM, Nat Sakimura <sakim...@gmail.com> wrote: > Generally speaking, mapping PUT to replace and POST to change is an > acceptable practice so I am fine with it. > > Now, what I still do not understand is why you think it is fine to do > PUT or POST and not DELETE. Doing PUT with empty content is almost the > same as DELETE. Could you explain? > > =nat via iPhone > > Feb 14, 2013 0:10、John Bradley <ve7...@ve7jtb.com> のメッセージ: > >> I am not violently opposed to PUT as a option that completely replaces the >> resource setting all unsent claims back to the defaults. >> >> I don't have a good feeling about DELETE, I think we still need more >> discussion on what it means, what privileges it takes to invoke it etc. >> It could be a bad thing if we get wrong or is not implemented consistently. >> >> Personally I don't think a client should ever be able to DELETE it's record. >> >> I think marking a client_id as pending provisioning, suspended, revoked etc >> is better and that can be done with a claim in the update endpoint. >> >> It should only be the server that deletes a record after satisfying it's >> audit requirements. >> >> John B. >> >> On 2013-02-13, at 12:00 PM, Justin Richer <jric...@mitre.org> wrote: >> >>> Would it be reasonable to mark the PUT and DELETE methods as optional for >>> the server to implement, but with defined semantics if they do? I want to >>> keep GET and POST(create) as mandatory, as I think that's the minimal set >>> of functionality required. >>> >>> -- Justin >>> >>> On 02/11/2013 08:51 PM, John Bradley wrote: >>>> 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
