Returning a location header in the 201 ids fine as long as we also have the same info as a claim.
I think most clients will want to process the JSON and store all the parameters together. Making them fish out a header makes the W3C happy and is the correct thing to do but taking it from a claim is what developers are more comfortable with. John B. On 2013-02-12, at 11:25 AM, Justin Richer <jric...@mitre.org> wrote: > I'd be fine with the return from a creation request being a 201 instead of a > 200. > > -- Justin > > On 02/11/2013 06:33 PM, Richard Harrington wrote: >> Since the request is an HTTP POST and a resource is created >> (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5) the response >> should be an HTTP 201 Created >> (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.2) which is >> supposed to include the location of the newly created resource. >> >> This is a good pattern to follow since, as you say, it does provide >> flexibility. >> >> >> >> On Feb 11, 2013, at 1:14 PM, Justin Richer <jric...@mitre.org> wrote: >> >>> Draft -05 of OAuth Dynamic Client Registration [1] returns a URL pointer >>> for the client to perform update and secret rotation actions. This >>> functionality arose from discussions on the list about moving towards a >>> more RESTful pattern, and Nat Sakimura proposed this approach in the OpenID >>> Connect Working Group. This URL may be distinct from the Client >>> Registration Endpoint URL, but draft -05 makes no promises as to its >>> content, form, or structure, though it does contain implementor's notes on >>> possible methods. >>> >>> Two questions arise from this change: >>> - The semantics of returning the client manipulation URL >>> - The syntax (derived from HAL for JSON [2], an individual I-D submission) >>> >>> On semantics: >>> >>> Pro: >>> - The server has flexibility on how to define the "update" endpoint, >>> sending all clients to one URL, sending different clients to different >>> URLs, or sending clients to a URL with a baked-in query parameter >>> - The client can take the URL as-is and use it for all management >>> operations (ie, it doesn't have to generate or compose the URL based on >>> component parts) >>> >>> Con: >>> - The client must remember one more piece of information from the server at >>> runtime if it wants to do manipulation and management of itself at the >>> server (in addition to client_id, client_secret, registration_access_token, >>> and others) >>> >>> Alternatives include specifying a URL pattern for the server to use and all >>> clients to follow, specifying a query parameter for the update action, and >>> specifying a separate endpoint entirely and using the presence of items >>> such as client_id and the registration access token to differentiate the >>> requests. Note that *all* of these alternatives can be accommodated using >>> the semantics described above, with the same actions on the client's part. >>> >>> >>> On syntax: >>> >>> Pro: >>> - Follows the designs of RFC5988 for link relations >>> - The HAL format is general, and allows for all kinds of other information >>> to be placed inside the _links structure >>> - Allows for full use of the JSON object to specify advanced operations on >>> the returned endpoint if desired >>> >>> Con: >>> - The rest of OAuth doesn't follow link relation guidelines (though it's >>> been brought up) >>> - The HAL format is general, and allows for all kinds of other information >>> to be placed inside the _links structure >>> - The HAL-JSON document is an expired individual I-D, and it's unclear what >>> wider adoption looks like right now >>> >>> Alternatives include returning the URL as a separate data member >>> (registration_update_url), using HTTP headers, or using JSON Schema. >>> >>> -- Justin >>> >>> >>> >>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05 >>> [2] http://tools.ietf.org/html/draft-kelly-json-hal-03 >>> _______________________________________________ >>> 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
