Agreed - I didn't think that header-only was the proposal, but let's be
explicit about the returned body always containing the URL. The way I
read the 201 definition, it suggests (SHOULD) that you use the location
header, but also says that the entity should refer to the new resource.
It was my assumption that the returned JSON would still have some form
of client-entity management URL (whether it's the HAL _links structure
or registration_management_url or something else is still up for debate).
-- Justin
On 02/12/2013 10:28 AM, John Bradley wrote:
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
<mailto: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
<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 <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
