EntityResource: read-only (GET) support for configuration entities

Just got rid of debug line and some old commented out lines.

In \Drupal\rest\Tests\ReadTest::testRead we have

// Only assert one example property here, other properties should be
      // checked in serialization tests.

Is this still true? Is there any use in making a ConfigTest class in REST to test or property of the test configuration objects that make sure config entities are being returned correctly?
If not then we probably won't need ConfigTest class until we support updating them.

curl --user admin:admin --request GET "http://drupal.d8/entity/taxonomy_vocabulary/tags?_format=json" | json_pp

{
   "description" : "Use tags to group articles on similar topics into categories.",
   "hierarchy" : 0,
   "weight" : 0,
   "_core" : {
      "default_config_hash" : "lO5ziR5dVI1PpEeHZsSOfQ-Y7NWihSDKW8-MMf6uoms"
   },
   "langcode" : "en",
   "vid" : "tags",
   "uuid" : "aba325c0-c57f-4bea-8daa-4792133eeb29",
   "dependencies" : [],
   "status" : true,
   "name" : "Tags"
}

What is this _core? Should we filter out '_' values?
Is it OK to expose default_config_hash?

Using a non-admin user + basic auth I get access denied although having REST permission to view taxonomy is set.

curl --user clemens:clemens --request GET "http://drupal.d8/entity/taxonomy_vocabulary/tags?_format=json&XDEBUG_SESSION_START=12889" | json_pp
{
   "error" : ""
}

The code checks for 'administer taxonomy' which make reading a vocabulary useless for getting the name of the vocabulary.

//core/lib/Drupal/Core/Entity/EntityAccessControlHandler.php:149
    if ($admin_permission = $this->entityType->getAdminPermission()) {
      return AccessResult::allowedIfHasPermission($account, $this->entityType->getAdminPermission());
    }

We need view permission for config entities.

+++ b/core/modules/rest/src/Plugin/rest/resource/EntityResource.php
@@ -48,13 +50,16 @@ public function get(EntityInterface $entity) {
@@ -95,9 +100,11 @@ public function post(EntityInterface $entity = NULL) {

@@ -95,9 +100,11 @@ public function post(EntityInterface $entity = NULL) {
     // Only check 'edit' permissions for fields that were actually
     // submitted by the user. Field access makes no difference between 'create'
     // and 'update', so the 'edit' operation is used here.
-    foreach ($entity->_restSubmittedFields as $key => $field_name) {
-      if (!$entity->get($field_name)->access('edit')) {
-        throw new AccessDeniedHttpException("Access denied on creating field '$field_name'");
+    if ($entity instanceof FieldableEntityInterface) {
+      foreach ($entity->_restSubmittedFields as $key => $field_name) {
+        if (!$entity->get($field_name)->access('edit')) {
+          throw new AccessDeniedHttpException("Access denied on creating field '$field_name'");
+        }
       }
     }
 
@@ -109,7 +116,13 @@ public function post(EntityInterface $entity = NULL) {

@@ -109,7 +116,13 @@ public function post(EntityInterface $entity = NULL) {
 
       // 201 Created responses return the newly created entity in the response
       // body.
-      $url = $entity->urlInfo('canonical', ['absolute' => TRUE])->toString(TRUE);
+      if ($entity->getEntityType()->hasLinkTemplate('canonical')) {
+        $url = $entity->urlInfo('canonical', ['absolute' => TRUE])->toString(TRUE);
+      }
+      else {
+        $url = Url::fromRoute('<front>')->setAbsolute()->toString(TRUE);
+      }
+
       $response = new ResourceResponse($entity, 201, ['Location' => $url->getGeneratedUrl()]);
       // Responses after creating an entity are not cacheable, so we add no
       // cacheability metadata here.
@@ -212,6 +225,9 @@ public function delete(EntityInterface $entity) {

@@ -212,6 +225,9 @@ public function delete(EntityInterface $entity) {
    *   If validation errors are found.
    */
   protected function validate(EntityInterface $entity) {
+    if (!$entity instanceof FieldableEntityInterface) {
+      return;
+    }
     $violations = $entity->validate();

This [edit]post code[/edit] belongs not in this issue as this is about to view a config entity

Assigning to myself to work on the issues noted above.

What is this _core? Should we filter out '_' values?
Is it OK to expose default_config_hash?
I would agree we should filter them out. They seem to be pretty internal.

Was looking into this. It seems weird to be filtering out different values.

I could see a use case you might want to default_config_hash externally.

What if you had a decoupled admin application that was maintaining multiple Drupal sites. If the application was keeping config entities on their side default_config_hash would be 1 way of keeping track of which config entities came from environments that were from the same install(dev, stage, prod of the same site).

Removed post code from the patch

@tedbow thanks for cleaning up a bit.

My #9 is not fixed. Do you have any idea?

@clemens.tolboom I agree with @dawehner in #11

Total good point! It feels like having this as a follow up seems to be a good idea. It conceptually doesn't belong into the issue we have.

We should make a follow up issue for exposing permissions for Config Entities once this is fixed

Hmmm I miss read #11.

We need to make clear this patch only works for users with permission administer taxonomy [edit]or other permissions depending on request.[/edit]

1. +++ b/core/lib/Drupal/Core/Entity/Controller/EntityController.php
   @@ -229,6 +229,10 @@ public function title(RouteMatchInterface $route_match, EntityInterface $_entity
   +  public function configController() {
   +    return [];
   +  }
   

   I think this can be deleted? :)

2. +++ b/core/lib/Drupal/Core/Entity/Routing/EmptyRouteProvider.php
   @@ -0,0 +1,36 @@
   +/**
   + * @file
   + * Contains \Drupal\Core\Entity\Routing\EmptyRouteProvider.
   + */
   

   Nit: we don't do this anymore since 8.2.

3. +++ b/core/lib/Drupal/Core/Entity/Routing/EmptyRouteProvider.php
   @@ -0,0 +1,36 @@
   +class EmptyRouteProvider implements EntityRouteProviderInterface {
   ...
   +    if ($link_template = $entity_type->getLinkTemplate('canonical')) {
   +      $entity_type_id = $entity_type->id();
   +      $route = new Route($link_template);
   +      $route
   +        ->setDefault('_controller', '\Drupal\Core\Entity\Controller\EntityController::configController')
   +        ->setRequirement('_entity_access', "{$entity_type_id}.view")
   +        ->setOption('parameters', [
   +          $entity_type_id => ['type' => 'entity:' . $entity_type_id],
   +        ]);
   +      $routes->add("entity.{$entity_type_id}.canonical", $route);
   +    }
   
   +++ b/core/modules/config/tests/config_test/src/Entity/ConfigTest.php
   @@ -20,7 +20,10 @@
   + *       "default" = "\Drupal\Core\Entity\Routing\EmptyRouteProvider",
   

   I don't understand this name at all.

   It's meant to be another default route provider I think, but then it then omits "default" from the name unlike \Drupal\Core\Entity\Routing\DefaultHtmlRouteProvider.

   Even more confusingly, it's called "Empty". Why? It's not always empty.

4. +++ b/core/modules/rest/src/Plugin/Deriver/EntityDeriver.php
   @@ -69,6 +69,9 @@ public function getDerivativeDefinitions($base_plugin_definition) {
   +          'serialization_context' => [
   +            'entity_type' => $entity_type_id,
   +          ],
   
   +++ b/core/modules/rest/src/Plugin/Type/ResourcePluginManager.php
   @@ -17,6 +17,13 @@
   +  protected $defaults = [
   +    'serialization_context' => [],
   +  ];
   
   +++ b/core/modules/rest/src/RequestHandler.php
   @@ -57,7 +58,7 @@ public function handle(RouteMatchInterface $route_match, Request $request) {
   -          $unserialized = $serializer->deserialize($received, $class, $format, array('request_method' => $method));
   +          $unserialized = $serializer->deserialize($received, $class, $format, array('request_method' => $method) + $definition['serialization_context']);
   

   Do we need this? AFAICT it's not used anywhere. I suspect it was used for methods other than GET, but that means this is out of scope here too.

5. +++ b/core/modules/rest/src/Plugin/rest/resource/EntityResource.php
   @@ -48,13 +50,16 @@ public function get(EntityInterface $entity) {
   +    if ($entity instanceof FieldableEntityInterface) {
   
   @@ -212,6 +217,9 @@ public function delete(EntityInterface $entity) {
   +    if (!$entity instanceof FieldableEntityInterface) {
   

   Why not typehint to ContentEntityTypeInterface? I suspect I know why, but this should be explicitly documented.

Here is patch the removes the serialization_context logic because it is not need for read.

It also adds comments that explains EmptyRouteProvider

82 KB patch vs 13 KB before. Something unwanted snuck in there :)

Whoops!!!

Okay here is an updated patch.

1. +++ b/core/lib/Drupal/Core/Entity/Controller/EntityController.php
   @@ -230,6 +230,18 @@ public function title(RouteMatchInterface $route_match, EntityInterface $_entity
      /**
   +   * Provides a generic callback for Configuration Entities.
   +   *
   +   * @return array
   +   *   An empty render array.
   +   */
   +  public function configController() {
   +    // Configuration entities do not have common view concept so default to an
   +    // empty array.
   +    return [];
   +  }
   

   The reason we have this was given in #21: Well, the requirement here is to provide a canonical route. Here we provide an empty controller in order to not have to think about how to implement a view builder for a config entity.
   

   Is it really impossible to get around this? Having this controller is very confusing/icky.

   If we need this, then why do we have this in EntityResource:

    *     "canonical" = "/entity/{entity_type}/{entity}",
   

   and this in EntityDeriver:

           $default_uris = array(
             'canonical' => "/entity/$entity_type_id/" . '{' . $entity_type_id . '}',
             'https://www.drupal.org/link-relations/create' => "/entity/$entity_type_id",
           );
   
           foreach ($default_uris as $link_relation => $default_uri) {
             // Check if there are link templates defined for the entity type and
             // use the path from the route instead of the default.
             if ($link_template = $entity_type->getLinkTemplate($link_relation)) {
               $this->derivatives[$entity_type_id]['uri_paths'][$link_relation] = $link_template;
             }
             else {
               $this->derivatives[$entity_type_id]['uri_paths'][$link_relation] = $default_uri;
             }
           }
   

   Why can't we rely on those defaults?

   Because we don't want /entity/vocabulary/tags, but we want /vocabulary/tags instead? If so, we should be updating all of the config entities' annotations too, otherwise this just works for config_test entities, which is less than helpful.

   This also indicates this is missing test coverage for config entity types other than config_test. Finally, this needs test coverage for a config entity type that does not have a canonical route. Because having a canonical route is an opt-in thing, so we must verify the behavior for those config entity types that don't have it.

2. +++ b/core/lib/Drupal/Core/Entity/Routing/EmptyRouteProvider.php
   @@ -0,0 +1,40 @@
   + * view route but need a canonical route for REST requests
   

   Nit: missing trailing period.

3. +++ b/core/lib/Drupal/Core/Entity/Routing/EmptyRouteProvider.php
   @@ -0,0 +1,40 @@
   + * ¶
   

   Nit: Trailing space.

4. +++ b/core/lib/Drupal/Core/Entity/Routing/EmptyRouteProvider.php
   @@ -0,0 +1,40 @@
   +class EmptyRouteProvider implements EntityRouteProviderInterface {
   

   I'd rename this to EmptyCanonicalRouteProvider.

5. +++ b/core/modules/rest/src/Plugin/rest/resource/EntityResource.php
   @@ -48,13 +50,16 @@ public function get(EntityInterface $entity) {
   +    if ($entity instanceof FieldableEntityInterface) {
   
   @@ -212,6 +217,9 @@ public function delete(EntityInterface $entity) {
   +    if (!$entity instanceof FieldableEntityInterface) {
   

   Can we document why we're not checking \Drupal\Core\Entity\ContentEntityInterface? #21 contains the answer.

When I remember correctly the point is that all kind of other code reacts to the canonical link path being there.

What are all those things then? And why is it not broken today?

Stuff like config translation calls to $entity->toUrl('canonical')

So how can config translation work today then?

Hah! :) I don't think at all you added it for fun! But I think for this patch to be committable, we at least need to understand why canonical URLs for config entities are a necessity.

I can only speak for myself, of course. And I have to say that I personally don't understand why we need this. We don't seem to be using it. As I said #26.1, I don't understand why we're adding a canonical route for config_test, but not for any other entity type. That makes it look like this issue itself doesn't actually add read-only/GET support for config entities: it looks like this only adds support for reading config_test config entities. That's a good step, but doesn't do what the issue title says.
So, assuming that we indeed must add a canonical route for every single config entity type, that means:

1. we need a follow-up issue for updating every single config entity type in Drupal 8 core
2. worse: it means contrib/custom config entity types actually won't be available over REST!

I sincerely hope that I'm wrong on both counts.

I hope this clarified where I'm coming from.

I also just grepped #2350509: Implement auto-route generation for all core entities and convert all of the core entities. for comments mentioning config entities. And based on #2350509-178: Implement auto-route generation for all core entities and convert all of the core entities., #2350509-201: Implement auto-route generation for all core entities and convert all of the core entities. and #2350509-202: Implement auto-route generation for all core entities and convert all of the core entities., it doesn't look like there was even agreement on how to deal with canonical for config entities there. So it seems wrong to start introducing it here?

So, per #26-#31, this needs documentation, a change record and an issue summary update. I think mostly the same text can be shared among them.

Per #26.1, I think this needs tests to show how this behaves for a config entity type that doesn't have a canonical route.

Ok I removed the need in the test to have a canonical url for config entities.

This got rid of the EmtpyRouteProvider and updated ReadTest to handle entities without canonical urls.
So now config_test entity does not have a canonical url.

I have not addressed any other issues in this patch

I'll make sure to follow up on #2733097: [FEATURE] Add GET support for configuration entities when this gets in. It feels that we may be able to reuse code/concepts from this patch.

Update the patch

Mh, so we change the expected behaviour in the test rather than expecting the behaviour which will happen on the actual site? This feels wrong, honestly. Won't have those entities actually have canonical link templates?

This whole change that was being commented on shouldn't have gone in. It was a problem in how I read the original patch. It actually is checking for access to the user entity, $account, because that resource is NOT rest enabled. I updated the comment so that it will be more obvious.

It seems like this patch now works expect that it sounds like we are going to address the permission of viewing configuration entities in another follow up issue. So that would be mean if this patch got in only user with "administer [CONFIG ENTITY TYPE]" could actually use rest to View configuration entities

Here is patch that addresses #37 and also add taxonomy_vocabulary entity to ReadTest

I think we really should not enable those routes as long we don't have any form of validation in place:

I chatted with @dawehner on IRC about this. He was in favor of leaving the routes but adding validation saying methods other than GET aren't supported on config entities.

I this patch I overwrote availableMethods in EntityResource to remove these methods. To me this seems better because:

1. availableMethods "Returns the available HTTP request methods on this plugin." which seems like should not include methods PUT, PATCH, DELETE on config entities
2. If we left the methods there then the permission would also be exposed which would be confusing
3. The restui module would allow you to configure them. I check this patch removes them from configuration

Nitpick: The $url->setRouteParameter($entity_type, $entity_id) call could be moved inside the else.

I intentionally left this outside the else because if the method is receiving a value for $entity_id to test creating a URL for an non-existing entity then you would want to override it in both cases. Setting it if you are just using $entity->id() also doesn't cause a problem.

I wrote this in #32:

So, per #26-#31, this needs documentation, a change record and an issue summary update. I think mostly the same text can be shared among them.

Per #26.1, I think this needs tests to show how this behaves for a config entity type that doesn't have a canonical route.

The first thing is yet to be done. The second thing is effectively addressed. Although I personally would like to see proof that more config entities can be read, e.g. block, field_storage_config, role.

I don't have any actual further complaints besides nitpicks. Leaving at NR.

1. +++ b/core/modules/rest/src/Plugin/rest/resource/EntityResource.php
   @@ -256,4 +264,32 @@ protected function getBaseRoute($canonical_path, $method) {
   +      // Currently only get is supported for Config Entities.
   

   Nit: s/get/GET/

2. +++ b/core/modules/rest/src/Tests/RESTTestBase.php
   @@ -367,6 +376,12 @@ protected function entityPermissions($entity_type, $operation) {
   +        // Currently only view is support by rest for configuration entities.
   

   Nit: s/view/viewing/, s/rest/REST/

3. +++ b/core/modules/rest/src/Tests/RESTTestBase.php
   @@ -367,6 +376,12 @@ protected function entityPermissions($entity_type, $operation) {
   +          // Currently there is no view permissions on configuration entities.
   

   IMO useless comment, because the prior comment already implies this.

4. +++ b/core/modules/rest/src/Tests/ReadTest.php
   @@ -91,6 +121,7 @@ public function testRead() {
        ]));
   +
      }
   

   Unnecessary change.

5. +++ b/core/modules/rest/src/Tests/ReadTest.php
   @@ -111,8 +142,50 @@ public function testResourceStructure() {
   +   *   The entity to get the url for.
   

   s/url/URL/

6. +++ b/core/modules/rest/src/Tests/ReadTest.php
   @@ -111,8 +142,50 @@ public function testResourceStructure() {
   +   *   The format for the URL.
   

   Not the format for the URL… The format to request the entity in.

7. +++ b/core/modules/rest/src/Tests/ReadTest.php
   @@ -111,8 +142,50 @@ public function testResourceStructure() {
   +   *   The entity id to use in the URL.
   +   *   Defaults to the entity's id if know given.
   

   Single line, and s/id/ID/

8. +++ b/core/modules/rest/src/Tests/ReadTest.php
   @@ -111,8 +142,50 @@ public function testResourceStructure() {
   +   *   The URL object.
   

   s/URL/Url/

9. +++ b/core/modules/rest/src/Tests/ReadTest.php
   @@ -111,8 +142,50 @@ public function testResourceStructure() {
   +      // name. This would give a route not found exception.
   

   s/route not found exception/RouteNotFoundException/

+++ b/core/modules/rest/src/Plugin/rest/resource/EntityResource.php
@@ -256,4 +264,32 @@ protected function getBaseRoute($canonical_path, $method) {
+    $entity_type = \Drupal::entityTypeManager()->getDefinition($entity_type_id);

Just noticed I didn't update this to use dependency injection. Fixing this and other issue in @Wim Leer's review

Ok here is the patch that addresses @Wim Leers' review in #39. It also has 2 fails \Drupal\rest\Tests\ReadTest::testRead which I will explain.

Although I personally would like to see proof that more config entities can be read, e.g. block, field_storage_config, role.

I have added testing for these entities. We could add more but could do that as part of #2737719: EntityResource: Provide comprehensive test coverage: for every entity type, every format, every method

Adding field_storage_config ran into 2 problems.

1. Field UI had to be enabled because the permission for field entities are defined there. @see #2562855: Fields cannot be administered without Field UI module
2. Even with the "administer node fields" permission you still can't read a field storage config on nodes. This is because there is no single admin permission for fields and there is not an entity access controller for Field Storage entities like there is for field Config entities(FieldConfigAccessControlHandler). If you look at \Drupal\field_ui\Routing\RouteSubscriber you will see array('_permission' => 'administer ' . $entity_type_id . ' fields'), for field storage but _entity_access used for field config routes.

This feels like a separate issue where FieldStorageAccessControlHandler would be introduced and \Drupal\field_ui\Routing\RouteSubscriber should updated to use it.

But I wanted to put this patch with failing test out there and get feedback. IMO we should remove field_storage_config from the entities to check because we know it will fail for none REST reasons, i.e. in \Drupal\rest\Plugin\rest\resource\EntityResource

  public function get(EntityInterface $entity) {
    $entity_access = $entity->access('view', NULL, TRUE);
    if (!$entity_access->isAllowed()) {
      throw new AccessDeniedHttpException();
    }

is correct but fails because the problem mentioned.

So, per #26-#31, this needs documentation, a change record and an issue summary update. I think mostly the same text can be shared among them.

This remains to be done.

This feels like a separate issue where FieldStorageAccessControlHandler would be introduced and \Drupal\field_ui\Routing\RouteSubscriber should updated to use it.

But I wanted to put this patch with failing test out there and get feedback. IMO we should remove field_storage_config from the entities to check because we know it will fail for none REST reasons

+1! This makes sense.

Thanks for adding tests proving that it works for multiple config entity types. That raises the confidence we can have in this patch.

I took care of updating the documentation:

• https://www.drupal.org/documentation/modules/rest -> https://www.drupal.org/node/1972016/revisions/view/9383538/9764041
• https://www.drupal.org/developing/api/8/rest -> https://www.drupal.org/node/2667736/revisions/view/9755775/9764057

So, remaining tasks:

1. removal of field_storage_config from test coverage, out of scope change required for that one to work
2. CR
3. IS update

+++ b/core/modules/rest/src/Plugin/rest/resource/EntityResource.php
@@ -286,7 +331,7 @@ public function availableMethods() {
   protected function isConfigEntityResource() {
     $entity_type_id = $this->getPluginDefinition()['entity_type'];
-    $entity_type = \Drupal::entityTypeManager()->getDefinition($entity_type_id);
+    $entity_type = $this->entityTypeManager->getDefinition($entity_type_id);
     $class = $entity_type->getClass();
     $interfaces = class_implements($class);
     return in_array('Drupal\Core\Config\Entity\ConfigEntityInterface', $interfaces);

+++ b/core/modules/rest/src/Tests/RESTTestBase.php
@@ -446,4 +454,60 @@ protected function assertResponseBody($expected, $message = '', $group = 'REST R
+    $entity_type = \Drupal::entityTypeManager()->getDefinition($entity_type_id);
+    $class = $entity_type->getClass();
+    $interfaces = class_implements($class);
+    return in_array('Drupal\Core\Config\Entity\ConfigEntityInterface', $interfaces);

This looks a bit wonky. But it's also what \Drupal\Core\Entity\TypedData\EntityDataDefinition::getPropertyDefinitions() does.

Note that you can make this much simpler:

$entity_type_id = …;
return $this->entityTypeManager->getDefinition($entity_type_id) instanceof \Drupal\Core\Config\Entity\ConfigEntityType;

removal of field_storage_config from test coverage, out of scope change required for that one to work

This patch does that and simplifies \Drupal\rest\Plugin\rest\resource\EntityResource::isConfigEntityResource and \Drupal\rest\Tests\RESTTestBase::isConfigEntity according to @Wim Leers' suggestion

I took care of updating the documentation:

Thanks!
So, remaining tasks now

1. CR
2. IS Update

I hope to take care of those this afternoon.

To me this patch looks ready.

Just one remaining nit, but keeping at Needs review:

+++ b/core/modules/rest/src/Plugin/rest/resource/EntityResource.php
@@ -30,6 +35,48 @@
+   * @var \Drupal\Core\Entity\EntityTypeManager
...
+   * @param \Drupal\Core\Entity\EntityTypeManager $entity_type_manager
...
+  public function __construct(array $configuration, $plugin_id, $plugin_definition, array $serializer_formats, LoggerInterface $logger, EntityTypeManager $entity_type_manager) {

Should typehint to the interface.

Fixed type hints

Mainly for follow up I did quick check to see if there were other config entity types that are like field_storage_config in that they don't have an admin permission and don't have there own access controller. From my understanding standing this would mean they won't be available for REST GET.

Here are the ones I found:

1. config_query_test|Test configuration for query
2. editor|Text Editor
3. field_storage_config|Field storage
4. rdf_mapping|RDF mapping
5. tour|Tour
6. entity_form_display|Entity form display
7. entity_view_display|Entity view display
8. base_field_override|Base field override

I think the good news is there is only 7 out 30 for the modules I enabled in core.

field_storage_config would actually be important for a headless client because as it is now it is the only way to figure out if a field is multiple value or not

Created change record https://www.drupal.org/node/2665276
and updated Issue Summary

Remaining tasks: none?!

Committed 6a16932 and pushed to 8.2.x. Thanks!

+++ b/core/modules/rest/src/Tests/RESTTestBase.php
@@ -200,14 +201,14 @@ protected function entityCreate($entity_type) {
+   *   The id of the type of entity that should be created.

@@ -431,4 +452,49 @@ protected function assertResponseBody($expected, $message = '', $group = 'REST R
+   *   The entity type id to check.
...
+   *   The id of the type of entity that should be created.

+++ b/core/modules/rest/src/Tests/ReadTest.php
@@ -111,8 +144,50 @@ public function testResourceStructure() {
+   *   The entity id to use in the URL, defaults to the entity's ID if know

Should be ID... fixed on commit.

Yay!

Published https://www.drupal.org/node/2746015.

Updated the issue that was blocked on this: #2300677-74: JSON:API POST/PATCH support for fully validatable config entities.

Was discussing this issue in light of #2135829: [PP-1] EntityResource: translations support. The way read support is exposed for config entities here if I am not mistaken is via their current loaded values which may be in the current translation, may contain environment specific overrides, domain overrides, etc. As per the discussion in #2135829: [PP-1] EntityResource: translations support, that makes the endpoints deal with different data based on which language prefix is present in the URL for example. Is that desired? Was that considered or should there be a followup for that?