Ideally, I'd find a way to seamlessly annotate values with information about where they came from, without disrupting the models of the inner layers of the architecture.
|2||added 173 characters in body|
How to create useful error messages in a JSON REST API without leaking implementation details across layers?
We're implementing a REST service with three main layers: Controller, Domain, Repository.
The REST API is supposed to respond to error conditions with meaningful error messages. Suppose the general layout of a payload given to a POST request were something like this:
Now, say we have an error somewhere down the line, and
But the entities in the repository and domain may look very different from the controller entities.
So, how do I report adequately which fields in the original JSON are affected when an error is raised in the repository?
I'm using Kotlin. Say my repository data structure looks like this:
whereas in the controller it probably looked something like this:
So if, say, my data base backend rejects
Right now, all options I have are kind of bad:
Raise very specific errors, that are always mapped to a particular REST input field
That's an OK approach for few and simple data structures, but it breaks down once the data structures become dynamic, or even overly complex, since you'll end up with a zoo of enums/error types.
Annotate all values that pass down to the controller with source information
Since I can't have annotations with retention
This adds a ton of indirection everywhere and makes my domain and repository hellish to test, as I need always wrap everything in pointless source pointers.
Have a look up table that co-ordinates domain and repository entities with REST source pointers
The idea would be to map repository entity fields and domain entity fields to controller entity fields in an explicit lookup table, whether through strings or even reflection (property names.)
Now there's an object in my program that knows about all layers, and breaks every time I change anything in any of the layers. That's not good!
Bottom line: We're stumped. How do we create useful error messages for our clients without breaking architecture encapsulation between layers? We haven't found good answers on the Net.