body of http response for write?

[neonstalwart]

is there something meaningful which could be returned in the body of the http response for a request to write? maybe the normalized batch points?

[beckettsean]

What is the goal of having a return value? To know whether the write succeeded? To gather statistics on the write?

[neonstalwart]

the motivation comes from typical REST APIs where the resulting resource is often returned as the response body. since the values provided to be written are not normalized, it could be useful for the client to receive the normalized points as the response body.

ultimately though, it was a little surprising to receive a completely empty response body. I blindly tried to parse the response as JSON and when that failed was when I discovered there was no response body at all. presumably if there is an error the response body will contain a JSON object that may provide details? if so, then it would make sense for all responses to at least be JSON parsable. if not, then maybe it should?

[beckettsean]

We do want to have some return, just trying to decide what is best.

A parseable JSON response of some sort seems reasonable in all cases, but to return data per-point means the return call will be nearly as big as the write call itself. Given the relatively low importance of any given point (for typical influxDB use cases) that feels like overkill.

Maybe an HTTP 200 OK or some very simple JSON for successful batches, perhaps including the total points written? For failed points we could report something, not entirely clear to me what would be easy to return.

[neonstalwart]

my use case might be different to the typical case. I'm tracking user interactions in a social network - more or less a self-hosted google analytics where users can pay for their own dashboard. I typically just send one point and honestly I discard the response so it's not significant and this is the reason I've posed this issue as a question. I was just caught by surprise when the response wasn't parsable.

[beckettsean]

We aren't a REST API even though it is an HTTP API, so in this case the 200 OK response is likely sufficient. No news is good news. On error we generally return some useful errors as JSON.

I'll make a note to document the expected responses a bit better.

[neonstalwart]

...it is an HTTP API, so in this case the 200 OK response is likely sufficient.

what do you think about switching to 204 for an empty response?