Add a derivative view for each comment field providing a REST export of comments for commented entities

Maybe comment should ship with a view by default?

Oh yeah I was more referring to your choice of using rest module as component.

1. +++ b/core/modules/comment/config/optional/views.view.node_comments_rest.yml
   @@ -0,0 +1,245 @@
   +status: true
   

   I guess we want to disable it by default so sites don't accidentally leak data?

2. +++ b/core/modules/comment/config/optional/views.view.node_comments_rest.yml
   @@ -0,0 +1,245 @@
   +tag: REST
   

   Nice!

3. +++ b/core/modules/comment/config/optional/views.view.node_comments_rest.yml
   @@ -0,0 +1,245 @@
   +      access:
   +        type: perm
   +        options:
   +          perm: 'access comments'
   ...
   +        status_node:
   +          value: true
   +          table: node_field_data
   +          field: status
   ...
   +      arguments:
   +        nid:
   +          id: nid
   +          table: node_field_data
   +          field: nid
   +          relationship: node
   

   What kind of access logic do we actually expect? People with access to the parent entity should have access to the individual comments?

4. +++ b/core/modules/comment/config/optional/views.view.node_comments_rest.yml
   @@ -0,0 +1,245 @@
   +      pager:
   +        type: full
   +        options:
   

   Any reason to use a full pager, not a mini one?

5. +++ b/core/modules/comment/config/optional/views.view.node_comments_rest.yml
   @@ -0,0 +1,245 @@
   +      row:
   +        type: fields
   +        options:
   

   Really fields? I would just expose the entire comment.

6. +++ b/core/modules/comment/config/optional/views.view.node_comments_rest.yml
   @@ -0,0 +1,245 @@
   +        node:
   +          id: node
   +          table: comment_field_data
   +          field: node
   

   If you use the entire comment you also don't have issues with not displaying the data for the parent entity. It would be just included all the time.

Comments are not unique to nodes anymore, so this should be done in a not-node-specific way. Also, to be properly RESTy we should have a link from the entity to its comment resource. Which means auto-generating the route information using a route provider.

How that fits in with using a View for the data itself... I'm not actually sure off hand. :-/

There is the possibility of multiple comment threads too, so lets not limit ourself to a single field either

Ah, so if this runs off Comment entities - if we change the uri to comments/{entity_type_id}/{entity_id} and add an argument that filters using the entity_type_id column/field on Comments, it should be generic enough to support all entity-types. Then we'd just need a new link-template in the commented entity-type » something like 'comment-thread'. This could be done in comment_entity_type_alter by looping over comment-types and collecting all of the target entity types - Something like this:

function comment_entity_type_alter(&$entity_types) {
  if (\Drupal::moduleHandler()->moduleExists('views')) {
    $comment_types = CommentType::loadMultiple();
    foreach ($comment_types as $id => $comment_type) {
      $target_type = $comment_type->getTargetEntityTypeId();
      $entity_types[$target_type]->setLinkTemplate('comment-thread', 'comments/' . $target_type . '/{' . $target_type . '}');
    }
  }
}

We could also accept an optional field-name to make it extra useful comments/{entity_type_id}/{entity_id}/{field_name}?

Then when we generate the hal representation of a node with commenting enabled, we could add a link to the 'comment-thread' using the link template.

Thoughts?

That's where the optional field name will come in, but could easily be the comment-type too - both are base fields on Comment entity, so should be available as arguments.