REST module: PUT/update

This seems pretty important to having web services in core.

Looks pretty straightforward to me. Hopefully we can sort the dependencies quickly.

added link to sandbox

The question is now how this operation should work on the entity API level. A PUT request has to completely replace the existing entity. Currently with this patch properties that are omitted do not get removed as they should. We also need test cases for this, which we currently do not have.

Sounds to me like we should do an entity_create() and pass in all the stuff that came from the incoming PUT. We should make sure that entity->id is set. Then, call entity->save. At no point did we call entity_load(). Sound good?

"A PUT request has to completely replace the existing entity. Currently with this patch properties that are omitted do not get removed as they should."

This feels debatable. HTTP/1.1 just says that:

If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server.

The intention of the client is to modify an existing resource with a new representation of this resource. The new representation only supersedes the representation that the client would retrieve in a GET method.

As a consequence, only the fields that would be present in the representation that would be generated for that particular client (in a GET request) should be taken into account. Fields that the client doesn't have access to should remain completely unaffected.

@Damien - the existing rest services don't care about access controlled fields either (CREATE, READ, ...). I agree that this is non-ideal and that we need to discuss it in its own issue. I've opened #1866908: Honor entity and field access control in REST Services. In the meanwhile, when you grant a role the rest permissions, you are granting full access to entity fields.

This is ready.

Sorry, but this is not ready. The current approach cannot flight. We cannot just throw away the old entity completely, as it can contain technical information that should not be touched (created date, etc.).

PUT has never been intended to be the equivalent of DELETE + PUT. In our case, the proper algorithm for PUT needs to be:

• Load the original entity, if it doesn't exist, throw a 404 (because we don't intend to support creating entities with PUT for now);
• Check that the original entity matches any conditional headers (If-Match / If-None-Match / If-Modified-Since) of the PUT request; if not, throw a 409 Conflict; (this cannot be implemented for now, because we still don't have proper ETag for entities);
• Validate that the replacement entity is valid, if not throw a 400 or 403;
• Merge the replacement entity with the old entity;
• Call save; on success, return 204; on error throw a 400 or a 500 depending on the error.

Check that the original entity matches any conditional headers (If-Match / If-None-Match / If-Modified-Since) of the PUT request; if not, throw a 409 Conflict; (this cannot be implemented for now, because we still don't have proper ETag for entities);

#1869338: Support ETag + If-Match for PATCH requests to prevent concurrent updates

Good to go. We'll tackle entity validation in #1696648: [META] Untie content entity validation from form validation

Committed to 8.x. Thanks.