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
