[pp-2] Support ConfigEntity via REST

Config entities have no validation and access API beside their UI's/Forms, so exposing over REST is tricky.

If we'd want that, it would be clearer if that would be a completely separate plugin and serialization, that would just directly use toArray().

Yeah, I agree that access checking should be sufficient for config entities. We have been moving away from route-based access (i.e. using _permission directly) to entity-level access for config entities so that should work fine. And in terms of validation we can use the new SchemaCheckTrait. It's not as powerful as content entity validation, but I think it too should be sufficient to validate that nothing completely bogus enters the system.

Maybe, but that still means that it would be a separate plugin for config entities and IMHO a feature request, not a bug. The only bug seems to be that you can configure rest.module to expose config entities right now an it's then choking on it...

What services supported and not is not really relevant, a feature in a contrib module doesn't mean that not having it in core is a regression :) Especially because 7.x did not differentiate between config and content entities, services.module did not integrate entities in a generic way and system is not an entity :)

If one config entity is supported then all are.

Configuration being what it is in Drupal, exposing it even behind permissions is a little like exposing custom module code if you've got the right permission. The delicate balance there seems pretty good for Contrib to explore, and maybe something gets into 8.1.

In practice, I expect it's not the full config entity you need, but some externally useful information (e.g., the name of a vocabulary), associated with the content it configures. Full CRUD support for Config would make this an API for building your Drupal site, and that seems like a glaring potential for massive security problems.

In an effort to constrain scope. the REST team decided to focus on content entities and not config entities. I'd be happy if someone took up this important feature. Retitling and recategorizing accordingly.

I'm no REST expert, but from what I can tell, the main problem is validation when modifying config entities.

What if core would only support reading config entities? That'd satisfy the majority and still defer the most complex parts to contrib.

During the Spring of DrupalCon Amsterdam 2014 I did a debug of how get via Rest Config Entity

I did my test with Entity entity:entity_form_display and the URL I use test was http://example.com/entity/entity_form_display/node.article.default after pass the Basic Auth I got a Access Denied 403.

The access denied was trigger in Resource Drupal\Core\Entity\Entity\EntityFormDisplay. because the class Drupal\rest\Plugin\rest\resource\EntityResource tried to execute the method access and doesn't exist.

I will improve the function get of Class EntityResource

public function get(EntityInterface $entity) {
    if (!$entity->access('view')) {
      print_r(get_class($entity));
      throw new AccessDeniedHttpException();
    }
    foreach ($entity as $field_name => $field) {
      if (!$field->access('view')) {
        unset($entity->{$field_name});
      }
    }
    return new ResourceResponse($entity);
  }

ASAP I got a patch I will upload.

Uhhh my fault, I will review and provide a feedback if works for Entity Form Display

Hi folks

I did a patch to support Entity Display entities via Rest, fixing the error trying to call access method with view parameters, also add current validation to confirm the user has access to get Entity Display definition.

To test this patch you can use the Chrome plugin Simple REST Client and the URI http://example.com/entity/entity_form_display/node.article.default remember enable the resource using the Rest UI module as you can see in the following image

As you can see in configuration you must to use Basic Auth in Rest Client and be sure the header Accept with application/json

As result you will get something similar to this output

{
    "uuid": "a3283201-6a27-41a4-a400-bfbd7550fd54",
    "langcode": "en",
    "status": true,
    "dependencies": {
        "entity": [
            "field.field.node.article.body",
            "field.field.node.article.comment",
            "field.field.node.article.field_image",
            "field.field.node.article.field_tags",
            "node.type.article"
        ],
        "module": [
            "comment",
            "entity_reference",
            "image",
            "path",
            "taxonomy",
            "text"
        ]
    },
    "id": "node.article.default",
    "targetEntityType": "node",
    "bundle": "article",
    "mode": "default",
    "content": {
        "title": {
            "type": "string_textfield",
            "weight": 0,
            "settings": {
                "size": 60,
                "placeholder": ""
            },
            "third_party_settings": []
        },
        "body": {
            "type": "text_textarea_with_summary",
            "weight": 1,
            "settings": {
                "rows": 9,
                "summary_rows": 3,
                "placeholder": ""
            },
            "third_party_settings": []
        },
        "field_tags": {
            "type": "taxonomy_autocomplete",
            "weight": 3,
            "settings": [],
            "third_party_settings": []
        },
        "field_image": {
            "type": "image_image",
            "weight": 4,
            "settings": {
                "progress_indicator": "throbber",
                "preview_image_style": "thumbnail"
            },
            "third_party_settings": []
        },
        "uid": {
            "type": "entity_reference_autocomplete",
            "weight": 5,
            "settings": {
                "match_operator": "CONTAINS",
                "size": 60,
                "autocomplete_type": "tags",
                "placeholder": ""
            },
            "third_party_settings": []
        },
        "created": {
            "type": "datetime_timestamp",
            "weight": 10,
            "settings": [],
            "third_party_settings": []
        },
        "promote": {
            "type": "boolean_checkbox",
            "settings": {
                "display_label": "1"
            },
            "weight": 15,
            "third_party_settings": []
        },
        "sticky": {
            "type": "boolean_checkbox",
            "settings": {
                "display_label": "1"
            },
            "weight": 16,
            "third_party_settings": []
        },
        "comment": {
            "type": "comment_default",
            "weight": 20,
            "settings": [],
            "third_party_settings": []
        },
        "path": {
            "type": "path",
            "weight": 30,
            "settings": [],
            "third_party_settings": []
        }
    },
    "hidden": [],
    "third_party_settings": []
}

@-Enzo- thanks, works for me! =)

HI @clemens.tolboom I did a new patch following your recommendation, please check and let me know if works for you.

Hi @clemens.tolboom

I remove unrelated code and fix indentation

@clemens.tolboom how I can do this " this needs tests too to confirm the GET versus other ops work as expected."?

I've tried the patch to get the contents of the main menu. (The path in REST UI is incorrect. The /entity part is missing)

curl --user admin:admin --header "Accept: application/json" --request GET http://drupal.d8/entity/menu/main

The response is correct but useless:

{
    "uuid": "2ee5aa01-b45d-46f0-9d06-6be711cdcedc",
    "langcode": "en",
    "status": true,
    "dependencies": [],
    "id": "main",
    "label": "Main navigation",
    "description": "Use this for linking to the main site sections.",
    "locked": true
}

The thing I needed was the items in the menu, not the metadata of the main menu.

Hi @MartijnBraam

About the missing entity in end point, maybe you need to update the Rest UI module I did a patch to resolve that issue #2290605: REST URI paths changed to canonical paths.

About the entity menu did you request, after enable the Entity Menu Resorce as you can see in the following image.

When I tried to consume this end point using the URL http://example.com/entity/menu/main I got the following error

[Wed Oct 15 06:35:14 2014] [error] [client 127.0.0.1] PHP Fatal error: Call to a member function access() on a non-object in /Users/enzo/www/drupal8beta/core/modules/rest/src/Plugin/rest/resource/EntityResource.php on line 52

I will debug and propose a new version of patch.

Attached you can find a new patch testes Menu, Nodes and Entity Display Form

Hi @clemens.tolboom

Using you patch #35 I did a new patch, because the way you use to get the Id of plugin return empty because is not an object is an array, but if you test with admin user the validation never is executed.

About the test I can't test because I'm getting a awful error trying to list the test to execute.

[Thu Oct 16 05:18:09 2014] [error] [client 127.0.0.1] Uncaught PHP Exception ReflectionException: "Class Drupal\\Tests\\devel_generate\\DevelGenerateManagerTest does not exist in expected /Users/enzo/www/drupal8/modules/devel/devel_generate/tests/src/DevelGenerateManagerTest.php" at /Users/enzo/www/drupal8/core/modules/simpletest/src/TestDiscovery.php line 153, referer: http://drupal8/admin/config/development/testing/settings

ASAP I resolve this issue I will work in testing, but meanwhile do you have any idea what is wrong in test? Also the test must be cover in this issue or maybe we can create a new issue?

@clemens.tolboom I follow your instructions and remove the devel issue, but now I got a new error if I try to run any Test you can see the error at #2341997: Uncaught exception - Circular reference detected for service "database".

Maybe you can consider to separate the Test in other issue and if work the patch apply to Drupal Core.

Any thoughts?

Hey folks

I did a re-roll of path #38 to meet the latest changes in Drupal 8 but still works in Unit Test are required.

Hi all. Tried the patch in 42 (support_configentity-2300677-42.patch), and still getting the metadata for menu:

curl --user admin:admin -H "Accept: application/hal+json" --request GET http://d8.local/entity/menu/footer
{"uuid":"3f36ed88-a631-4614-8601-1d7c9ae394c1","langcode":"en","status":true,"dependencies":[],"id":"footer","label":"Footer","description":"Use this for linking to site information.","locked":true}

Is this patch supposed to pull the actual menu items?

No, the patch is not. Menu links are something else entirely. The menu config entity *is* the menu metadata.

I still have the opinion that providing generic support for config entities is problematic and unneeded. In many cases, they will not give you the data you actually care about. See above.

The only real use case I see for the current content entity implementation is to synchronize data 1:1 between equal systems, e.g. a staging/production site. It is an internal representation of the raw data.

For config entities, we have the configuration sync/import API, and nothing we do could do here would come close to what that provides, with diffs, and sync flags and so on.

IMHO, if you want an API that you can use from an external source, e.g. an app, or a public API for your clients, especially if that involves config entities but likely even for content, then write it yourself, then you can define an API and structure that makes sense for your use case. Take the example in #43, where the expectation is to get all the menu links, which are actually plugins, with different sources. There is no way we can make a generic API that supports that, but it should be fairly easy to write a custom resource plugin that returns menu links in a simple structure.

@Berdir I use this patch with a Headless Drupal Generator github.com/enzolutions/generator-marionette-drupal , in my case is good idea because in that way I can generate HTML5 forms based in Drupal 8 site current status.

I know you point an API is only for data, but with proper permissions you can expose this information to create great tools and services integrated with Drupal 8

Yeah, I really don't understand how you can write a custom front-end for a Drupal 8 site without supporting at least some config entities. The inability to get vocabulary names when displaying a node is a huge limitation.

@clemens.tolboom Correct you can solve that with view because is content.

But in my case I want to create a REST Frontend #headless Drupal with Backbone with the capability to generate Forms for content types based in current content types definition in a Drupal 8 site, how you can solve that with out expose a config entity?

If you check the patch the rest resource require a specific permission to access config entities, so IMHO is not security issue. Also a Rest Resource has a security level with Authentication Provider selected when the Rest Resource is enabled.

If the argument to disable this option is force users to create content in Drupal instead of provide the option the user to decide how access his content even the admin content is the wrong angle.

Hey folks

I did a re-roll of path #42 to meet the latest changes in Drupal 8 but still works in Unit Test are required.

Kicking of the testbot to see if we need a re-roll....

Not sure if this should still be 8.0 or 8.1 but, I will see if I can reroll this patch.

I worked a bit on it, here are some bits I ran into it on the meantime.

Looks great!

+++ b/core/modules/rest/src/Plugin/rest/resource/EntityResource.php
@@ -210,6 +216,9 @@ public function delete(EntityInterface $entity) {
   protected function validate(EntityInterface $entity) {
+    if (!$entity instanceof FieldableEntityInterface) {
+      return;
+    }

Shouldn't we perform config schema validation for config entities? See \Drupal\Core\Config\Schema\SchemaCheckTrait — hattip @tstoeckler in #5.

Closed #2650792: What permissions control REST's field_storage_config? as a duplicate, another person wondering why this doesn't work, and the lack of helpful errors also getting in the way.

I think it's safe to say this is at least major.

Made some progress:

• The create test now actually works, yeah
• Started to expand the read test

Note: This is blocked on #1928868: Typed config incorrectly implements Typed Data interfaces technically, doesn't mean though one cannot work here.

Let's be more honest about it.

Let's work first of the GET aspect of things, see #2724823: EntityResource: read-only (GET) support for configuration entities

what does pp-2 mean?