Build a custom logger

[juliusmarminge]

The API's current logging system is quite all over the place. different errors are reported in their own structure, some examples are

# /api/<version>/sensors/[id]
400: { formErrors: [], fieldErrors: { id: ["Required."] } }
404: { message: "Sensor with sensor id 1 not found." }
500: { error: "Internal server error." }

The suggestion is to have the logger report errors that are structured the same way, perhaps:

400: { code: "sensors/id_required", message: "A required parameter `id` was not provided." }
404: { code: "sensors/not_found", message: "Could not find a sensor with id 1" }
500: { code: "server_error" message: <An actual representation of what went wrong> }

[andreas-bauer]

I don't like the idea of having a code field inside of the return structure.
The standardized HTTP status code should be used to describe the type of response/error.
An additional code field doens't provide enough value to justify the maintenance overhead with custom codes.
Custom codes need to be documented and an consitent use through the whole application must be ensured.

I would suggest having a message field that the describes the problem good and using the standardized HTTP status codes. If a good message is not enough you could add an error field that contains everything that a try-catch-block catched as error message. But I'm not sure if this is really needed. As always, keep it simple until you really need it.

{
"message" : "Good description of the problem",
"error": "error message that is catched from another func call" // not sure if really needed
}

[juliusmarminge]

Yes this was not something I meant should be implementerad now. The error messages are good and often clearly tells what went wrong.

The problem now is simply that all errors are formatted differently which doesnt adhere to the "design-cheat-sheet" you sent us: https://r.bluethl.net/how-to-design-better-apis#heading-10-use-standardized-error-responses

[andreas-bauer]

Hi, I understood that you want to uniform the error respones and I agree on that.
My point is, that in your proposal you have the field code: "sensors/id_required" which itself is not a good idea since it doesn't provide any value and is redundant with the HTTP status code and the URL for the ressource.

[juliusmarminge]

Okay, got you! The format I proposed came straight from that guide I linked previously.

The format is something you could finalize later. The implementation of this logger is not in our backlog for this project, perhaps a later group can take this on another time.