[FEATURE] Multiple operations in one request

Agreed. I thought a little bit about this, and I would even go further. I believe that there is no reason not to have a non-REST related module that is a generic web service.

That module would have a front controller. That front controller would semantically represent the entire content repository. Maybe /transactions. That controller would only accept POST or PATCH requests with a payload. That payload would contain a set of sequential transactions (we could get in async stuff later) to execute.

Every transaction will have all the information that an individual regular JSON API transaction should have encoded in that payload:

• The payload for write operations.
• The headers for that transaction.
• The path of the operation. Ex: /api/node/article
• The operation (that maps to an HTTP verb). Ex: read, add, update, replace, delete, explore
• The query string parameters. Ex: {"filter": {"field_tags": {"value": "6"}}}
• A list of cookies to pass along from the initial request to the front controller. An option to pass them all.

With that information we can manually create the request object and have the jsonapi module do the processing and process the result.

The response would be an array of JSON API document root responses, each one corresponding to the original transaction.

As you can see there is little that stops us from having a transactions socket instead of a /transactions HTTP endpoint. So this jsonapi_transactions module could not even be constraint by HTTP (although we may want to leave that for the future).

Note that there is no intention to call this proposal REST. It is as RPC as it can be, but that is not a bad.

This proposal is heavily inspired (almost a direct import) of the ideas @dgeb is proposing in the JSON API discussion thread.

If anything this should happen in a separate contrib. Closing.