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
<mailto: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 <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
