Pass entity_type into Serializer via context

entity_type should not be a problem, we could place serialization context parameters on the resource plugin information.

The subtype is a problem since that information is only present in the data, not in the URL, not in the plugin info, not in some HTTP headers.

Should the deserialization normalizer for entities just perform an entity load if an ID is present? It could get the subtype from the loaded object.

Here is a patch that demonstrates how the deserialization context could be built. It passes entity_type and resource_id on to the serializer and deserialization chain.

#3: rest-deserialize-context-1964034-3.patch queued for re-testing.

bump.

Rerolled #3. This needed ->id() and a line removed in core/modules/serialization/src/Normalizer/EntityNormalizer.php which puzzles me.

Let's see what the testbot finds.

Drupal\Tests\serialization\Unit\Normalizer\ConfigEntityNorma   1 passes
PHP Fatal error:  Call to a member function hasKey() on a non-object in /var/lib/drupaltestbot/sites/default/files/checkout/core/modules/serialization/src/Normalizer/EntityNormalizer.php on line 55
PHP Warning:  Invalid argument supplied for foreach() in /var/lib/drupaltestbot/sites/default/files/checkout/core/scripts/run-tests.sh on line 588

Warning: Invalid argument supplied for foreach() in /var/lib/drupaltestbot/sites/default/files/checkout/core/scripts/run-tests.sh on line 588

Drupal\rest\Tests\UpdateTest 59 passes 2 fails
Drupal\rest\Tests\NodeTest 33 passes 1 fails

Fatal error: Call to a member function hasKey() on a non-object in /var/lib/drupaltestbot/sites/default/files/checkout/core/modules/serialization/src/Normalizer/EntityNormalizer.php on line 55

FATAL Drupal\serialization\Tests\EntitySerializationTest: test runner returned a non-zero error code (255).

1. +++ b/core/modules/rest/src/Plugin/Derivative/EntityDerivative.php
   @@ -98,6 +98,9 @@ public function getDerivativeDefinitions($base_plugin_definition) {
   +            'entity_type' => $entity_type,
   

   Just use the ->id()

2. +++ b/core/modules/serialization/src/Normalizer/EntityNormalizer.php
   @@ -48,7 +48,7 @@ public function denormalize($data, $class, $format = NULL, array $context = arra
   -    $entity_type = $this->entityManager->getDefinition($context['entity_type']);
   +    $entity_type = $context['entity_type'];
   

   Reverted

3. +++ b/core/modules/serialization/src/Normalizer/EntityNormalizer.php
   @@ -58,7 +58,7 @@ public function denormalize($data, $class, $format = NULL, array $context = arra
   -    return $this->entityManager->getStorage($context['entity_type'])->create($data);
   +    return $this->entityManager->getStorage($context['entity_type']->id())->create($data);
   

   Reverted

Latest patch fixes the current issue, but seems to break PATCH requests (see failing tests).

Also the serialization_context annotation should be added to the Drupal\rest\Annotation\RestResource class so other developers know that it exists, what it does, and how they should use it.
Other annotations seem to be missing as well, the class only contains id and label at the moment.

As patch tests fail why not add the request_method back.

$context = array('request_method' => $method);

Not tested locally due to grogginess

@bertramakers can you please create a new issue regarding the annotations mentioned in #13. It's worth a new one.

(sigh) wrong order of setting array (key) value(s)

[edit]Irrelevant[/edit]

Initialize $context array.

Created issue for #13 #2359245: REST resource plugin annotation class misses some properties

@clemens.tolboom
I am a bit confused here, the issue title and IS talk about bundles, how they are added here?

@dawehner thanks for pointing out my 'blindness'. I did 'just a reroll' :-(

Updated the summary accordingly.

This will be particularly important if we create an EntityDiff class for PATCH requests.

The method \Drupal\rest\Plugin\rest\resource\EntityResource::patch does not use the non-existing EntityDiff either This issue is the only issue mentioning EntityDiff https://www.drupal.org/project/issues/drupal?text=entitydiff&version=8.x

I agree that at least the added serialization_context key should be added to the annotation at Drupal\rest\Annotation\RestResource.

And this needs a phpunit test case which demonstrates that a mocked serializer indeed receives the entity type in the serialization context.

This patch is now also partly implemented in #2291055: REST resources for anonymous users: register

This is comment and a question to hopefully help the next guy who comes along and is testing D8 REST functionality, since the stuff above is pretty technical.

As of drupal-8.0.0-beta6 it seems you can't do a PATCH (or POST according to https://www.drupal.org/node/2098511) using application/json because it will return an

"error": "Entity type parameter must be included in context."

However, using a hal+json and its _links type already works fine to do POST or PATCH.

Is one of the outcomes of this issue, and/or #2291005, that it will soon be possible to do a PATCH or POST with Content-Type: application/json ?

If so, it seems like including
"entity_type": "node"
in the application/json
would be necessary, correct?

@orangecoat-ciallella you are spot on.

This patch should make Content-Type: application/json work.

Maybe you could update the summary with your text from #29?

Patch doesn't apply anymore because EntityDerivative.php doesn't seem to exist anymore. I think it has been renamed to EntityDeriver.php somewhere in the past months. Can't find the related issue though.

@anavarre see #2406439: Cleanup EntityDerivative and RouteBuilderInterface

Removed bundle from title and summary

Open issues are

- needs annotation #27
- needs tests #27

Rerolled.

I also needed the $context['entity_type'] to be set. I did that with:

$context['entity_type'] = $definition['entity_type'];

It works, but I'm not entirely sure based on this ticket whether that's the correct way to be doing it or whether it should come from somewhere else.

entity_type should not be a problem, we could place serialization context parameters on the resource plugin information.

The subtype is a problem since that information is only present in the data, not in the URL, not in the plugin info, not in some HTTP headers.

#2631774: Impossible to update Comment entity with REST (HTTP PATCH): bundle field not allowed to be updated, but EntityNormalizer::denormalize() requires it also ran into this: for Comment entities, the subtype (bundle, called comment_type in their case) is not allowed to be modified (by any user, ever). Yet the denormalizer requires it. It therefore required a change in another layer, so the denormalizer gets it (step 1 in the pipeline), but not the entity that ends up being saved — it is stripped by the EntityResource (step 2 in the pipeline).

This is about Serializer context, so is #2568413: REST views: Pass views style plugin instance to REST Export serializer.

Updated for 8.2.x and updating issue summary. Without this, it is impossible would most likely require significant effort in the ECK module to POST ECK Entities, while with this applied, it just works.

My perspective on this has changed since I wrote #37 more than 14 months ago.

We've been able to use the Drupal 8 core REST API just fine all this time, with various entity types. #2737719: EntityResource: Provide comprehensive test coverage: for every entity type, every format, every method and the many follow-ups for it have proven that this is simply not necessary. Therefore, closing this.