Usually, I'd create DTO classes, map them to internal data classes and make sure that data written to the DB is always valid, by constraints and/or additional manual validation. But as the schema only describes API level objects, all validation would need to take place in the presentation layer.
If the analysis makes no mention of an internal DTO or even any internal implemenation whatsoever; then the analysis inherently cannot be stating something along the lines of "the validation must happen before an internal DTO is involved".
What this means is that you have free reign over where this validation takes place, as long as the implemented validation covers the entire API as expected. You could, purely theoretically, create 5 subsequent layers and only perform the requested validation at the bottom most layer.
Not that this is the right answer here, but the point is that the analysis does not tie you to having to perform your validation in a given layer when the analysis makes no layered distinction to begin with.
To simplify things, I could skip creating DTO classes at all and directly persist API classes in the DB.
I'm not one for blanket statements. Generally speaking, I'd avoid the conflation of entities and API models.
However, when dealing with a REST API whose sole purpose is to act as a web-based data repository which should always mirror the data store's structure and has no additional business logic whatsoever; an argument can be made that the returned API model must invariably be the entities without any possible reason for them to be different; at which point the advice to separate your entity/model dissipates.
This way, I would at least not have to map back and forth
Be very careful that you're not tricking yourself into this purely because you want to avoid writing some additional API models and mappings. Avoiding the effort is not sufficient justification in and of itself. This is a very dangerous corner to paint yourself in; one which only makes sense under very strict conditions.
The service itself will only do minor things with the data, like adding an id to newly created documents, which seems manageable even without model classes.
However tiny, this is a form of business logic, and it already starts infringing on your argument that you can get away with not separating your API models from your entities.
Still, after doing DTOs for so many years and basically being happy with it, I'm still somewhat reluctant to ditch them completely.
You didn't bring this up, but it's a likely next step on your train of thought: there's little sense in having a partial abstraction whereby some entities get an API model and others don't just doesn't make sense.
You either abstract or you don't. If you go half-and-half, you're signing yourself up for the negatives from both sides (the effort of maintaining the models plus the tight coupling that hampers future changes).
I know there's probably not the right or wrong answer, but does someone has experience with one or the other solution and maybe has a few hints on what to take care of?
"I could totally cut this corner" is a dangerous proposition. It is very easy to trick yourself into it, and it can be very hard to claw your way out of it again. It is one of the biggest Great Filters that software projects run into.
Alas, there is no quick argument to defeat all of the possible reasons (or delusions) that lead you to cutting too many corners. And, from personal experience, even if you provide an apt argument that disproves the benefit of cutting a given corner, there is no guarantee that the intended corner-cutter listens to/believes your advice.
Does that mean we should never ever cut a corner? No, because that too would be a blanket statement, and I told you I don't like blanket statements.
However, whenever we think that cutting a corner might be warranted here, we need to really think about what is driving us to make that decision; and double/triple/quadruple check that there are no ill consequences that we're failing to consider at the time of making our decision.
Personally, unless I have an ironclad argument as to why there are no ill consequences, or I am immune to ill consequences (e.g. a one time use script), I avoid cutting corners where possible, because it's often safer traveling on the road instead of going through the forest.