REST: 'count' on query should return application/json content-type and not text/plain

Currently, when sending a /queries/entity/somequery/count request, the response has a content-type of text/plain, whilst it should be application/json.

From a client point of view, API responses should be consistent with the overall purpose/surface of the API itself (or part of it). Or, alternatively, the API itself should support Accept request headers to select the appropriate content-type for the response.

The purpose of the entire queries resource endpoint (and in same regard the entities one) is to return data serialized in JSON representation.
Sending a text/plain response, containing a valid JSON value (it is a plain number), is a violation of such contract.


the issue is here:

Hi @gorbunkov
please raise the bar on this if possible, because today passing Accept: application/json on a call to /count returns a 406 response.

From your (current) POV it may seem ok, but it horribly break my automated REST client libraries, that constructs requests in a centralized place.
Now I can’t rely on /count calls because my entire library stack is JSON based…