Error feedback design

[CodeShellDev]

Hey there @bbernhard 👋,

I was wondering how your design standard for user feedback for errors is?
Do you prefer returning http error codes with simple message Bad Request: missing xyz or is error: "xyz" more common on the endpoints?

I guess most of the errors are handled at signa-cli level, but are there also errors that are created from SCRA?
What about the error codes? Do you have a preference on what error code to use for what?

Also what is the design behind the versioning? Does /v1/* use variables in the path and /v2/* rather just using the body?
What steps are taken going from /v1/* to /v2/*?

This is a bit of a more unusual question, but I would like to know this because I want to keep parity with error handling for my proxy (handling invalid timestamps, etc.).

Thanks in advance!

Sorry for the ping!

[bbernhard]

Hi,

you are right, most errors come directly from signal-cli and are returned as is. Most of the time, I've only added some input verification on top to verify that all the necessary parameters for signal-cli are provided. In case additional input verification makes the API more convenient to use, I've added it. I think all of the errors are returned in the format ({"error": "this is a error message"}) - at least that format is what I am using since a while now (there might be some old endpoints, where it is different though). For most of the errors I am returning the generic 400 status code - in case another more specific status code (e.g 404) makes more sense, it is used.

Something that is really important to me, is not breaking the API. i.e if an endpoint works in a specific way in one release, it must not change with the next release. That's why I've introduced /v2/send. /v1/send only allows to attach one attachment to a message - which is a bit of a limitation. /v2/send allows to attach multiple attachments.