Part 4: Should PUT or PATCH be allowed to change the id?

[philvarner]

I looked through the spec and could not find clear guidance on this, so I'm filing this ticket.

The semantics of a PUT or PATCH allow the entity to be changed. This means you could make this call:

PATCH /collections/c1/items/1 { "id": 2 }

This should presumably change the feature to have an id of 2, and thereby change the url to /collections/c1/items/2.

I think this should be explicitly disallowed, as the ID should considered immutable.

[pvretano]

@philvarner Part 4 will have a dependency on a schemas which is currently a proposal. The proposal defines a number of schema types: returnables, queryables, sortables, create, update, replace.

The update schema controls which properties a client is allowed to change via a PATCH. So, if a server did not want to allow the id property to be changed, it would not define it in the update schema. The replace schema performs a similar function for PUT.

At the OGC member meeting this week the SWG announced that we have more-or-less finished with Part 3/CQL2 and will now start working on the other parts & proposals so you should start seeing more activity on Part 4 and the schema proposal!

Hope this gives you some idea where we are heading ...

[cportele]

I think this should be explicitly disallowed, as the ID should considered immutable.

Meeting 2022-05-09: We agreed that changing the ID (the URI of resource) through PUT or PATCH has a bad smell. Is that even allowed in HTTP? Maybe through a permanent redirect? We should check and then decide whether it should be prohibited or a server decision.

[cportele]

After looking at the specification of PUT in HTTP, I think that it should be prohibited. The specification is quite explicit that only the representation is changed, but that it is the same resource:

The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request message content. A successful PUT of a given representation would suggest that a subsequent GET on that same target resource will result in an equivalent representation being sent in a 200 (OK) response.

[jvanulde]

@cportele if you mean that changing the the identifier be prohibited, then I would agree with you. Perhaps some guidance for a workaround might be welcomed? For example, an implementation could allow for a permanent redirect to a new resource created via HTTP POST.

[cportele]

Meeting 2022-06-06:

• We will not allow that PUT or PATCH changes the resource id (URI), based on the requirements in HTTP.
• A permanent redirect would be a possibility in general, but the API itself does not offer a capability to control that a new persistent redirect can be established.
• Another option would be to support the MOVE method from WebDAV, but this is out-of-scope for Part 4.

@cportele will check, if the document needs an update and create a PR, if necessary.