Intake API responses: Body and content type investigation/thoughts about apm-server HOT 3 CLOSED

I agree that we should include more descriptive error messages. This will be particularly useful for signaling that the apm-server internal queue is full or that it can't contact the upstream Elasticsearch (or kafka) etc. These will be 5xx responses.

In the apm-server, we'd include the error JSON payload if the agent sent an Accept header that allows for it (*/* or application/json etc.) and just return a plain text error if not.

I like error instead of message:

{"error": "foo bar baz"}

When looking at the payload you might not see that the response code is not a 2xx (and as you wrote, curl by default doesn't display the status code), so the error key instead of the message key clearly indicates that there was a failure. I don't feel strongly about it though.

from apm-server.

@watson can we agree on the above?

from apm-server.

@roncohen sounds good to me 👍 And good point with using error instead of message.

What do you want to do with 404 and 405 responses? Should they have a body at all? If so, I imagine that body should follow the Accept header as well.

from apm-server.