OK Tim do you think DELETE is a feature that: a) developers would use b) that Authorization servers like google would implement.
If we put it in and than have people say you have a bunch of extra stuff no line is going to use just to be semantically pure. I will not be a happy bunny. Just because HTTP has a verb we don't need to use it if we don't have a concrete use case. If you say Google would implement it and use it for x or y than I would feel differently about it. I don't hate DELETE though I think it is probably a bad power to give to clients. Feedback on your use case please. John B. On 2013-02-13, at 6:26 PM, Tim Bray <twb...@google.com> wrote: > 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
