On 02/12/2013 11:30 AM, John Bradley wrote:
To some extent we want the server to have the flexibility it needs.
If the server knows it is going to need client_id for GET it needs to encode it
in the resource URI ether as part of the path or as a query parameter (that is
up to the server)
When doing updates the client MUST include the client_id as an additional
integrity check. Some servers may switch on that but that is up to them.
So if by this you mean that the client still simply follows whatever
update url the server hands it (which may or may not include the
client_id in some form, but the client doesn't care), and that the
client MUST include its client_id in the request body (top-level member
of a JSON object, at the moment) when doing a PUT (or POST/PATCH? see
below) for the update action, then I'm totally fine with that. Is this
what you're suggesting?
If we want incremental replace (not resetting claims not sent to there
defaults) then we need POST for update.
I think if you want to do the REST thing and be pure about PUT it needs to
reset all values not sent to there defaults.
I agree with this argument in terms of the purity, and as I would rather
see the different verb used for different actions, I am willing to give
up the semantics of the not-resetting-claims that's in there right now
for this action. There's actually another HTTP verb, PATCH, that isn't
used much but is meant for partial updates, and we could transfer the
not-resetting-claims action to this instead.
I suppose we could have both but two ways of doing it leads to confusion.
I agree that we can't do both PUT and POST, and we can't have both
partial and complete replacement on the same verb/endpoint combination.
We need to pick one combination and have it be clear.
-- Justin
On 2013-02-12, at 11:52 AM, Justin Richer <jric...@mitre.org> wrote:
The problem that I have with "always including the client_id" is *where* to
include it. Are we talking a query parameter, URI template, or somewhere in the request
body? The latter will only work for POST and PUT, so it's out of the question to support
GET and DELETE using that semantic. I think we should support all operations using
parallel syntax -- that's just good API design.
I *really* don't like the idea of switching the action solely based on whether
or not the client_id is present in the request body of a POST. This is a
side-effectful mode switch, and it will only lead to pain and misery.
Additionally, if the input is JSON (separate discussion), then a server would
have to parse the JSON body before knowing where to route the request. In most
web development frameworks that I've used, this is impossible. A query
parameter or URL pattern, on the other hand, is doable.
As it stands right now, a server is free to include the client_id in the
"update/management" URL that it returns as part of the _link structure
(separate discussion). The current text goes as far as recommending that practice, but
doesn't take the step of requiring it in any form, and leaving it up to the server to
decide what form it takes. If a server can route better with a query parameter, it'll
return a URL to the client that has a client_id= query parameter. If a server would
rather use a path component with the client_id, it can do that, too. If it wants to put
everything on one URL and differentiate through the request body or presence/absence of
the registration_access_token, it can always return the same URL to every client. I think
that's nuts, but you can do it. Interoperability is preserved because the client simply
follows the returned URL to do its bits and pieces, and it doesn't ever have to create or
compose this URL from component parts.
I want to continue to distinguish between the POST and PUT operations for create and
update, respectively. This is a common pattern and the one described in the original REST
thesis that described the architectural style. I'll also bring up that the semantics of
PUT are intended to be "replace all", which is what you had originally argued
for in the update case as well. I not convinced that developers of today can't handle
HTTP verbs like PUT if they want to do fancier operations like updates. Note that the
core operations, create and read, remain as POST and GET, which would be well within the
grasp of every library and web developer today.
-- Justin
On 02/12/2013 02:23 AM, Torsten Lodderstedt wrote:
+1 for always including the client_id
As John pointed out, there could be different entities updating client data.
Then one has to distinguish the resource and the credential.
Am 12.02.2013 um 02:51 schrieb John Bradley <ve7...@ve7jtb.com>:
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
