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
