(Yikes, you’ve seen PUT used for partial replace? That’s…horrible. I’ve never seen that myself. We should definitely clarify, then. We do have a design principle that’s explicit about striving for RESTfulness.)Farazath, I suspect you may be looking at an old draft version of the RSR spec if you’re seeing a 204 on an example of PUT. I’m only seeing it in the example in the final Recommendation version of RSR Sec 2.3.4 for Delete, not RSR Sec 2.3.3 for Update or anywhere else (Kantara Recommendation, IETF I-D).BTW, I have a goal — if my jet lag allows — to add spec links and quotes to comments on the new GitHub issues by tonight, in order to assist with any spec interpretation questions where possible. If anyone else has thoughts/opinions/implementation experience, it would be great if you could do that in the coming week, as the WG leadership team will be presenting an analysis approach for assigning issue priorities and milestones on the next call.EveOn 19 Jul 2015, at 3:56 AM, Farazath Ahamed <mefarazath@gmail.com> wrote:Eve,
And what about the response to an update?
We can't send the 204 with a body right?On Sun, Jul 19, 2015, 3:53 PM Justin Richer <jricher@mit.edu> wrote:“PUT” only “means full replace” in the context of a well-defined specification that follows RESTful principles — but you could easily use it to mean whatever you want (and I’ve seen it done!). It’s much better in a spec to say exactly what it does and not assume.— JustinOn Jul 19, 2015, at 5:15 AM, Eve Maler <eve@xmlgrrl.com> wrote:You’re correct, a PUT is a full replace. (Way back when, I think we discussed including a PATCH method too, but discarded it as too complex.) The spec isn’t ambiguous because PUT means full replacement (here’s a discussion :-), but it wouldn’t hurt to clarify in belt-and-suspenders fashion if someone wants to put in an issue about it.EveOn 16 Jul 2015, at 5:07 AM, Justin Richer <jricher@mit.edu> wrote:I believe it's supposed to send all the attributes to comply with common RESTful design (a PUT is a full replace, a PATCH would be a partial update), though the spec is also ambiguous about that._______________________________________________
-- Justin
On 7/16/2015 8:06 AM, Farazath Ahamed wrote:
Thanks Justin
And for a small clarification,
Does the resource set description sent with a HTTP PUT only include the attributes to updated or the whole resource set description of the resource set?
You're correct, the example is wrong, and the normative text is ambiguous as it doesn't specify a response code. We implemented this as a 200. Additionally, we return the full entity on update since the text says the response "must include the _id" but doesn't specify whether or not to include anything else:
https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/blob/master/uma-server/src/main/java/org/mitre/uma/web/ResourceSetRegistrationEndpoint.java#L202-L204
I'd file a new bug.
-- Justin
On 7/15/2015 9:30 PM, Farazath Ahamed wrote:
Hi,
The method described in the spec to update Resource Set descriptions[1] is supposed to return a HTTP 204 including the _id value of the successfully updated resource set description.
but the HTTP Status Code Definition for 204 says,The 204 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields.
Therefore is it correct to include a body in a 204.Is it possible to do that? Am I missing a trick here?
A.Farasath AhamedUndergraduate | Department of Computer Science and Engineering,University of Moratuwa
Article Writer | MoraSpirit
Mobile: +94 777 603 866E-Mail: mefarazath@gmail.com
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma