Subject: [scim] Return of POST/PUT operations

From: Grahame Grieve <[email-masked]>
Date: Wed, 28 Jan 2015 23:42:58 +1100

Quoting from the current spec (section 3.3.1):

   Unless otherwise specified a successful PUT operation returns a 200
   OK response code and the entire resource within the response body,
   enabling the client to correlate the client's and the service
   provider's views of the updated resource

2 questions:
- why return the resource? under what circumstances can the 'views' be
different, and what would a client do about that? Why not just let the
client 'get' the resource if it wants to see the outcome, instead of
clogging up bandwidth with the reponse?
- "unless otherwise specified" - I did not see any information about how
that might be specified?

thanks
Grahame

-- 
-----
http://www.healthintersections.com.au / [email-masked]
/ +61 411 867 065

---

From: Julian Reschke <[email-masked]>
Date: Wed, 28 Jan 2015 14:29:35 +0100

> - "unless otherwise specified" - I did not see any information about how

<https://tools.ietf.org/html/rfc7240#section-4.2> might be of interest.

Best regards, Julian

---

From: Phil Hunt <[email-masked]>
Date: Wed, 28 Jan 2015 08:35:21 -0800

The general design principle has been to return the final representation. SCIM's primary objective is provisioning so letting the client know the final state has been the historical choice. Not saying whether this is good or bad, but it has been my impression from the original drafts. Maybe others have more historical context?

I am concerned about use of the returned header per sec 4.2 of 7340 as this adds more permutations besides http status 200 vs 204. 

Note: we are currently past last call but this may re-open due other bugs I will post today. 

Phil

> On Jan 28, 2015, at 05:29, Julian Reschke <[email-masked]> wrote:
> 
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: Julian Reschke <[email-masked]>
Date: Wed, 28 Jan 2015 17:42:04 +0100

On 2015-01-28 17:35, Phil Hunt wrote:
> ...

If you require 200 with the full resource state then you are profiling 
HTTP. It's better to avoid that, because if you have two conflicting 
profiles, you can't implement them on the same URI unless you do UA 
sniffing.

The Prefer header field gives you the hook that you need to specify a 
preference.

Best regards, Julian

---

From: Grahame Grieve <[email-masked]>
Date: Thu, 29 Jan 2015 09:03:10 +1100

that's very interesting, thanks

Grahame