I came across a statement that the domain model designed in accordance with DDD should not be used as resources in a REST API (source).
It is clear that a REST API is a contract of the application while the domain model is part of the implementation and therefore it is the best to keep these two things separate, so that a change in the domain model does not automatically imply a change in the REST API.
Should the domain and the REST models be separated?
When using DDD, the REST API should always be separated from the domain model.
The main reason for this is simplification - you don't want to leak the complexity of the domain model through the API to the clients. Otherwise, clients need to know about the nuances and intricacies of your domain, which most probably makes the API hard to use.
And the main driver for using DDD is a complex problem domain, so this is always a problem.
However, I think in case of small projects (…) the benefits of having separate models does not justify the cost of separating the models (…).
I agree that there are projects where a separated domain model and REST API is over-engineering. However, these cases aren't candidates for DDD, because you will not benefit from DDD enough to justify its cost.