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 <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
