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
.
-- Mike
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Justin Richer
Sent: Monday, February 11, 2013 1:15 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Registration: HAL _links structure and client self-URL
Draft -05 of OAuth Dynamic Client
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
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
Actually, if it is to return it in the HTTP header, then it should
also use the RFC5988 Web Linking format.
Now, that is nice to have, but for many JSON programmers, I agree that
it would be a hassle to obtain the header and store them in addition
to the JSON. So, it is nicer to have it in JSON
Subject: Re: [OAUTH-WG] Registration: HAL _links structure and client self-URL
Actually, if it is to return it in the HTTP header, then it should also use the
RFC5988 Web Linking format.
Now, that is nice to have, but for many JSON programmers, I agree that it would
be a hassle to obtain
...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Nat
Sakimura
Sent: Tuesday, February 12, 2013 9:11 AM
To: Justin Richer; oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: HAL _links structure and client self-URL
Actually, if it is to return it in the HTTP header, then it should also
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Nat
Sakimura
Sent: Tuesday, February 12, 2013 9:11 AM
To: Justin Richer; oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: HAL _links structure and client self-URL
Actually, if it is to return
...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Nat Sakimura
Sent: Tuesday, February 12, 2013 9:11 AM
To: Justin Richer; oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: HAL _links structure and client
self-URL
Actually, if it is to return it in the HTTP header, then it should also
; oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: HAL _links structure and client self-URL
Actually, if it is to return it in the HTTP header, then it should also use the
RFC5988 Web Linking format.
Now, that is nice to have, but for many JSON programmers, I agree that it would
be a hassle
] Registration: HAL _links structure and client
self-URL
Actually, if it is to return it in the HTTP header, then it should also
use the RFC5988 Web Linking format.
Now, that is nice to have, but for many JSON programmers, I agree that
it would be a hassle to obtain the header and store them
: [OAUTH-WG] Registration: HAL _links structure and client self-URL
Actually, if it is to return it in the HTTP header, then it should also use
the RFC5988 Web Linking format.
Now, that is nice to have, but for many JSON programmers, I agree that it
would be a hassle to obtain the header and store
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
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
14 matches
Mail list logo
