I'm fine with the use of the different verbs, provided that the client_id is
present to distinguish between "register" and "update" operations for
implementations that want to use it in that matter, as I'd previously written.
(*Your* implementation is free to not use this value, if you so choose, but
it's useful for many.)
If that's not acceptable, then we should restore the "operation" parameter.
I will add that "register" should be the only required operation. It's fine to
support others if needed in a particular context, but enabling registration of
clients shouldn't require servers to also support changing them, getting state
about them, and deleting them.
-- Mike
-----Original Message-----
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Justin Richer
Sent: Monday, February 11, 2013 1:15 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Registration: RESTful client lifecycle management
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
