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

Maciej Machulak maciej.machulak at gmail.com
Wed Aug 27 14:42:45 CDT 2014


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> 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] *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>
> 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
> mobile: +44 7999 606 767 (UK)
> mobile: +48 602 45 31 66 (PL)
>
> _______________________________________________
> WG-UMA mailing list
> WG-UMA at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-uma
>
>
>
>
> Eve Maler                                  http://www.xmlgrrl.com/blog
> +1 425 345 6756                         http://www.twitter.com/xmlgrrl
>
>
>



-- 
Maciej Machulak
email: 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/1a355840/attachment.html>


More information about the WG-UMA mailing list