Implement PATCH request for FedoraResource entities

[dannylamb]

Implement an endpoint that accepts PATCH requests at http://localhost:8000/fedora_resource/{id}.

• It should respect the Drupal/Symfony _format parameter.
• It should accept the Vclock header to perform conditional updates. E.g. if the provided header and the value in the DB are not the same, abort the operation because someone else has already updated it. This will be used for optimistic locking.

[whikloj]

Just to flesh this out. What would the possible contents of the BODY of this request be?

[dannylamb]

@whikloj It would be equivalent to what PATCH accepts for XML or JSON, but JSON-LD. So it would contain triples you want updated, but not the entire representation of the entity. Something akin to https://www.drupal.org/docs/8/core/modules/rest/4-patch-for-updating-content-entities, which shows you how it's done with HAL.

[ajs6f]

Is it something like this?

[dannylamb]

@ajs6f Not really. I was rolling with Drupal on this one. It expects enough info to load the entity (which is more than just an id, you need to know bundle as well), and then only the properties you want to get updated. There may be a little more wrapped in there, but couldn't tell you without more exploration.

[whikloj]

So funny story, this works for json right now. No actual work involved.

I enabled PATCH with json and basic auth. Then I created a RDF Source with some name.

Then I did

> curl -i -XPATCH -uadmin:islandora -H"Content-type: application/json" --data-binary '{"type":[{"target_id":"rdf_source"}], "name":[{"value":"BOOM"}]}' "http://localhost:8000/fedora_resource/1" 

HTTP/1.1 200 OK
Date: Thu, 23 Mar 2017 00:50:02 GMT
Server: Apache/2.4.18 (Ubuntu)
Cache-Control: must-revalidate, no-cache, private
X-UA-Compatible: IE=edge
Content-language: en
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Expires: Sun, 19 Nov 1978 05:00:00 GMT
X-Generator: Drupal 8 (https://www.drupal.org)
Content-Length: 758
Content-Type: application/json

{"id":[{"value":"1"}],"vid":[{"value":1}],"type":[{"target_id":"rdf_source","target_type":"fedora_resource_type","target_uuid":"af1cb3d8-2c1f-4ca1-a1c2-b1173704807f"}],"uuid":[{"value":"ded658d0-4210-4972-bd62-3090ea806ff9"}],"user_id":[{"target_id":"1","target_type":"user","target_uuid":"8bbfb873-e28c-486d-84a1-c200d5f0529d","url":"\/user\/1"}],"fedora_has_parent":[],"name":[{"value":"BOOM"}],"status":[{"value":"1"}],"langcode":[{"value":"en"}],"created":[{"value":"1490227017"}],"changed":[{"value":1490230202}],"promote":[{"value":"1"}],"sticky":[{"value":"0"}],"revision_timestamp":[{"value":"1490227017"}],"revision_uid":[],"revision_log":[],"revision_translation_affected":[{"value":"1"}],"default_langcode":[{"value":"1"}],"field_ldp_contains":[]}

and lo and behold the name of the resource had been updated.

If I don't pass the basic auth parameters you get a HTML page for access denied, but the headers are

> curl -i -XPATCH -H"Content-type: application/json" --data-binary '{"type":[{"target_id":"rdf_source"}], "name":[{"value":"Smack that"}]}' "http://localhost:8000/fedora_resource/1" 

HTTP/1.1 401 Unauthorized
Date: Thu, 23 Mar 2017 00:52:10 GMT
Server: Apache/2.4.18 (Ubuntu)
Cache-Control: must-revalidate, no-cache, private
WWW-Authenticate: Basic realm="Islandora-CLAW"
X-UA-Compatible: IE=edge
Content-language: en
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Expires: Sun, 19 Nov 1978 05:00:00 GMT
X-Generator: Drupal 8 (https://www.drupal.org)
Content-Length: 6527
Content-Type: text/html; charset=UTF-8

Thoughts?

[whikloj]

So I'm guessing this is not going to work for json-ld format, nor does it care about the vclock parameter. The json-ld is probably something we need to develop centrally so it can be used by all the HTTP operations, but I'll look to adding a requirement for the vclock.

[DiegoPino]

@whikloj but if it works for JSON, most of the heavy work is done, good finding!. the JSON-LD part would just need to map back to JSON representation Drupal already knows of (which are the fields, most likely the way post is doing that) and then execute all the logic JSON already applies. Sounds easy, but for sure it can have more complications. Probably when that logic goes into the serializer this operation should work natively for json-ld also.

[dannylamb]

Yeah, totally works right now. If we can't sort out the serializer in both directions before deadline, this is my fallback, lol.

[dannylamb]

@whikloj It's tricky. There doesn't seem to be a way to really alter existing REST resources, per se. Just ways to register your own plugin instead of the default. It's akin to making your own custom controller but having it work under the guise of the Drupal's REST system.

Maybe we could implement conditional updates with the version counter via middleware, but I haven't explored that approach enough.

[whikloj]

So what I am doing right now is just implementing hook_rest_resource_alter

Then pointing to my own class that extends the normal entity REST response class and just implementing my own patch function.

This seems to be behind the serialization layer as patch just gets the old entity and the new entity and you do your thing.
public function patch(EntityInterface $original_entity, EntityInterface $entity = NULL)

[dannylamb]

@whikloj Precisely. If you can get at the headers and add the conditional part there, I think it'd be great and provide a seamless Drupal experience.

I got pretty frustrated with it earlier and gave up on REST system, so maybe you're just the man we need to work through it.

[whikloj]

@dannylamb oh right I forgot that the vclock was a header 🤦‍♂️

This is going to need to be a routing alter, as the requirements are set on routes.

[whikloj]

Ok, I need some help here.

This is what I know. If the vclock is in the request body, I can compare it once we start processing the actual PATCH. That isn't really the Drupal way as the check should occur before it, but we don't get that until the entity is ready.

We can leave it as a header and perform a test like the CSRF-Token check, except that to validate the vclock we need to load the entity, to get the uuid to get the current vclock value.

But (and this is my lack of understanding of the "Drupal" way) you don't have both the request and the entity at the same time.

[DiegoPino]

@whikloj you could have request and the entity at the same time. Worst scenario: at least enough data to load the entity base on the request. Can you point me to a piece of code/existing functionality you would like to extend?
One good example of entity and request being at the same contex/same time are controllers that upcast (convert argument into object) entities like https://github.com/Islandora-CLAW/islandora/pull/33/files#diff-80c2a2a62b59c06233b678757a7bc4d6R27. I guess the REST project does something similar.

last idea, if you have the request object around, as we did in silex, you can further mash-it-up, decorate it, and add stuff to it (like an internal communication decive) only because the request object Drupal uses is not PSR-7 (inmutable)