+1 to this. And I'd also be fine if it wasn't MTI (server returns a 405
Method Not Allowed) for servers that don't want to do it at all.
-- Justin
On 02/13/2013 04:26 PM, Tim Bray 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
<mailto: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
<mailto: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
<mailto: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
<mailto: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
<mailto: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 <mailto:OAuth@ietf.org>
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto: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
