RestResource plugins: use get() method with optional parameter (or no parameter) to signal list support?

At least for me any kind of optional parameter makes things weird ...

I think the simplest alternative here would be to allow the resource plugin to control this behaviour.

a) Add a new interface looking sort of similar like this:

interface RestResourceCallInterface {
  public function call($request, $route)
}

b) The request handler could then call to the plugin instead of calling $response = call_user_func_array([$resource, $method], $arguments);

The problem here is that it's not one resource. It's two resources.

A "collection resource" is likely to support POST and GET. An "individual item resource" will probably support GET, PUT, PATCH, and DELETE.

Since the name implies plugins:resources as 1:1 relationships, then I would expect a second plugin for list support to keep it flexible.

Contrib/individual sites may want to extend behaviors on top of individual item resources to create a POST effect, for example triggering bulk delete of a collection.

@Grayside
Based upon my proposal you would get different routes passed along and as such you could make some decisions, which of your actual functions you want to call?

The proposal makes sense as a way of making the existing plugins more flexible to cover this use case. My counter argument to this approach is that it takes a RestResource plugin and makes it a single plugin for two resources. The temptation to combine them (and that might well be better for Drupal DX, not judging that) is because it's a common entity type associated with both.

You can argue it's a single resource with an optional parameter, but that variation on the URL/route only seems subtle because of the clean URL design. Collections of different entity types tend to have at least as much in common with each other as they do with the individual items of the collection.

You can argue it's a single resource with an optional parameter, but that variation on the URL/route only seems subtle because of the clean URL design. Collections of different entity types tend to have at least as much in common with each other as they do with the individual items of the collection.

At least I think optional parameters are a flaw. I think on the REST domain level there is no notion of optional parameters. There is a collection resource and there is an individual object resource.

I was reading a bit about REST interfaces across the interwebs. One thing I stumbled upon was https://en.wikipedia.org/wiki/Representational_state_transfer#Applied_to...
As you see there GET is not the only place where we could support collections. Interesting

#7 I think that would imply that all we need to do here is write documentation, in which we would recommend to write two REST resource plugins: one for individual resources, one for resource collections. Is that what you meant?

Well, either we do that, or we give them the freedom to provide custom methods. To be honest it is quite magical that the HTTP verb maps to the method name. It feels like it would have been nice if it would have been more explicit in the first place.