openid/sharedsignals

What is the semantic difference between PUT and PATCH in stream management?

Closed this issue · 1 comments

There does not appear to be normative text regarding the purpose and semantics of each of PUT or PATCH. Further there is no normative text explaining the differences.

The examples seem to suggest that PUT is an entire document swap, whereas PATCH only specifies changed data.

Even with PUT, there are some claims (e.g. stream identifier) which the requestor may not change (as they are immutable).

SCIM Protocol (RFC7643) ran into this and had to define what happens for differing attribute types that have differing mutability. For example, a PUT or PATCH updating a read-only attribute is ignored rather than generating an error. Similarly an attribute that was missing from PUT does not mean delete the attribute. Instead, SCIM PUT sets out what the client must do to delete or nullify an attribute. The use case in SCIM was a client GETs a resource (or a StreamConfiguration), modifies an attribute and PUTs it back.

In the case of stream management, I don't see the need for a PATCH operation. In contrast in SCIM, where groups are potentially very large objects, PATCHing them makes sense.

Since this will result in a breaking change if we do this, I'd like to close this issue. Please re-open if you think we should be working on this.