On 2013-02-12, at 1:39 PM, Justin Richer <jric...@mitre.org> wrote: > > 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?
Yes but It is a suggestion others may still hate it. > >> 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. Yes PATCH would represent the incremental update but we are getting further from the beaten path here. > >> 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
