[WG-UMA] Unnecessary "status" parameter for resource reg

Da Cruz Pinto, Marcelo marcelo.da.cruz.pinto at intel.com
Wed Aug 27 14:56:16 CDT 2014


Sure, couldn’t agree more! I was just trying to make sense of why the status field was added there in the first place.

I had not paid attention to the “_rev” field… that’s also a bit weird: for an HTTP client, it should typically be enough with the “ETag” header for caching purposes (the client should store the ETag next to the actual resource representation for future update operations). Putting the Etag value as a “revision” field on the body also goes a bit against RESTful guidelines (although I also understand this as a potential attempt to circumvent certain client-side limitations… but I’m not sure)

From: Maciej Machulak [mailto:maciej.machulak at gmail.com]
Sent: Wednesday, August 27, 2014 12:43 PM
To: Da Cruz Pinto, Marcelo
Cc: Eve Maler; UMA WG WG
Subject: Re: [WG-UMA] Unnecessary "status" parameter for resource reg

Hi Marcelo,

Thanks for your comments. The scenario on page 16, however, does not match the spec text; hence my suggestion that the "status" parameter is removed. I think there is some text that should be clarified. See Section 2.3.3:


   Updates a previously registered resource set description using the

   PUT method.  If the request is successful, the authorization server

   MUST respond with a status message that includes an ETag header and

   _id and _rev properties for managing resource set description

   versioning.



   Form of an "update resource set description" HTTP request:



   PUT /resource_set/{rsid} HTTP/1.1

   Content-Type: application/json

   If-Match: (entity tag of resource)

   ...



   (body contains JSON resource set description to be updated)



   Form of a successful HTTP response:



   HTTP/1.1 204 No Content

   ETag: "2"

   ...

The text requires _id and _rev in the response but the success HTTP response uses 204, which is probably the preferred one (although 200 is fine, too). The text and the scenario should be unified then.

Cheers,
Maciej

On 27 August 2014 20:25, Da Cruz Pinto, Marcelo <marcelo.da.cruz.pinto at intel.com<mailto:marcelo.da.cruz.pinto at intel.com>> wrote:
On page 16 there is a scenario where a resource is being updated, and hence the status field is “updated” instead of “created”. There is no status code for “updated” in the HTTP standard (this might have been the reason why the status field has originally added). Now, that said, I think that by just returning a plain 200 as a result of an HTTP PUT is ok.

Another argument against status (or other control) fields in RESTful responses is that they actually break the RESTfull tenets, in particular, the that the resource representation needs to be cacheable: If I perform an HTTP PUT on the resource, I need to get a representation of the resource that is the same (in structure) as if I had just created it using HTTP POST. To provide a better example, if I perform an idempotent HTTP PUT operation on the resource, and I get a status of “updated” this will break those guidelines because the original resource representation had a status value of “created” (but nothing really changed…)


From: wg-uma-bounces at kantarainitiative.org<mailto:wg-uma-bounces at kantarainitiative.org> [mailto:wg-uma-bounces at kantarainitiative.org<mailto:wg-uma-bounces at kantarainitiative.org>] On Behalf Of Eve Maler
Sent: Wednesday, August 27, 2014 7:19 AM
To: Maciej Machulak
Cc: UMA WG WG
Subject: Re: [WG-UMA] Unnecessary "status" parameter for resource reg

I'll create a new issue for this. Unless anyone wants to disagree, I think this is worth fielding in the run-up to V1.0.

Can anyone think of a reason why the UMA-specific field adds value to the HTTP-level return code?

          Eve

On 26 Aug 2014, at 3:18 PM, Maciej Machulak <maciej.machulak at gmail.com<mailto:maciej.machulak at gmail.com>> wrote:

In resource registration spec [1], we use the field "status" to inform the RS that a resource set is created on AS. This duplicates information that the RS obtains through HTTP return codes. Maybe this field should be removed?

Cheers, Maciej

[1] http://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-03

--
Maciej Machulak
email: maciej.machulak at gmail.com<mailto:maciej.machulak at gmail.com>
mobile: +44 7999 606 767<tel:%2B44%207999%20606%20767> (UK)
mobile: +48 602 45 31 66 (PL)
_______________________________________________
WG-UMA mailing list
WG-UMA at kantarainitiative.org<mailto:WG-UMA at kantarainitiative.org>
http://kantarainitiative.org/mailman/listinfo/wg-uma


Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756<tel:%2B1%20425%20345%206756>                         http://www.twitter.com/xmlgrrl




--
Maciej Machulak
email: maciej.machulak at gmail.com<mailto:maciej.machulak at gmail.com>
mobile: +44 7999 606 767 (UK)
mobile: +48 602 45 31 66 (PL)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/wg-uma/attachments/20140827/dbc277f3/attachment-0001.html>


More information about the WG-UMA mailing list