A DELETE is an http request that asks the server to delete something. We probably would want to avoid writing a requirement into the standard that the server has to comply. So you get back a 204 if it worked, a 404 if there is no such registration, a 403 if there is but the server declines to delete, etc. Seems pretty straightforward. -T
On Wed, Feb 13, 2013 at 12:18 PM, John Bradley <ve7...@ve7jtb.com> wrote: > 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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
