The current wording for updating relationships is too restrictive. Most noticeable it limits usage of extensions for endpoints used as relationship links.

For example, it forbids servers to support the atomic operations extensions on endpoints used for relationship links.

A server MUST respond to (...) POST, (...) requests to a URL from a to-many relationship link as described below.

For all request types, the body MUST contain a data member whose value is an empty array or an array of resource identifier objects.

This conflicts with atomic operations extension. The atomic operations extension specifies that a client may send a POST request with atomic:operations top-level member. The data top-level member must not be present. Supporting such a request on an endpoint used for relationship links as well would violate the specification if taking it by word.

This merge request changes the wording to allow extensions like atomic operations on these endpoints.

It does so by changing the wording to focus on the intend. It specifies how a request for updating relationships must look like. But does not put any constraints on other requests - even if using the same endpoint.

This aligns updating relationships with existing wording for creating, updating and deleting a resource.

Creating Resources

A resource can be created by sending a POST request to a URL that represents a collection of resources.

Updating Resources

A resource can be updated by sending a PATCH request to the URL that represents the resource.

Deleting Resources

An individual resource can be deleted by making a DELETE request to the resource’s URL: