Multiple APIs within the same Service and Content Negotiation


Hello everyone,

I’m using JSONAPI to implement Service-to-Service communication and Application-to-Service communication. I’d like to know if the following Content Negotiation strategy is aligned with JSONAPI 1.0.

Can I use the Accept header to the tell server which API I’d like clients to use?

Clients MUST send all JSON API data in request documents with the header Content-Type: application/vnd.api+json without any media type parameters.
Clients that include the JSON API media type in their Accept header MUST specify the media type there at least once without any media type parameters.

In the dependency diagram below, you can see that my Collector Service publishes two different APIs for two different supporting actors.


+-------------+                +-------------+
|             |                |             |
|  Collector  |                |  Harvester  |
|  Service    <----------------+  Service    |
|             |                |             |
+------+------+                +-------------+
       | application/vnd.dashboard-api-1.0+json
|             |
| Dashboard   |
| Application |
|             |

When the Harvester Service pushes data to the Collector it’d use:

POST /events
Content-Type: application/vnd.api+json
Accept: application/vnd.harvester-1.0-+json

When it’s the Dashboard Application the one pulling data, it’d use:

GET /events
Content-Type: application/vnd.api+json
Accept: application/vnd.dashboard-api-1.0-+json

I could express the same separation of concerns using namespaces in the URL, it’s my personal preference to keep URLs “clean”.

POST /harvester/1/events
GET /dashboard/1/events

I was wondering if the Content-Type vs Accept header would be considered still valid.


As far as I can tell, this is a server implementation detail since I cannot find anywhere in the spec where this is addressed. Generally, this is the purpose of the accept header.

That being said, if you want to remain spec compliant, you could consider building this out as an extension which allows you to tack on some other information to the headers.