Ideally none
But that's not always possible. I can't give you hard numbers like 20% or 10 lines, that is subjective to the point it can't be answered. I can describe how I use design patterns and circumstances that necessitate bending them slightly.
In my mind it's entirely up to the purpose of the application. Building a simple REST api to post to? Forget about clean separation or even a pattern. You can churn out a working version in under an hour. Building something bigger? Probably best to work on it.
Building individually contained systems is the goal. If you start writing business logic that is specific to how two systems interact that is a problem. Without looking further into it I can't give an opinion.
Design patterns are molds, some like to strictly adhere to them on the basis of principal and well-written code. Strictly adhering to a pattern probably won't give you bad code, but it could take more time and cause you to write much more code.
Design patterns are flexible, adjust them to suit your needs. Bend them too much and they break though. Know what you need and pick a design pattern closest to that.
The problem I see with your approach is that you are building a REST API for only one consumer, your controllers, and that's overkill. Don't just add a layer just to pass data from one layer to another, there's no point, you'll be creating work for yourself for no additional benefit.
One (quick) way to make your API useful would be if it was the only endpoint your controllers (i.e. your application) ever needs. Consider this:
Suddenly your REST API has a purpose, and that is to provide a unified interface to your various data providers. Your application doesn't need to know about the Google or the Trello API, or any other data provider you might use in the future, it just needs to know about your REST API.
This design, albeit slightly more useful, is still overkill if your application is the only consumer. The whole point of building a REST API is to expose a publicly available interface for your applications to share. And the key here is exposure, your REST API will be available to the world and therefore it must be secure. API authentication and authorization are no simple tasks, if only one application uses your API, why go through all the trouble? Unless of course you want to experiment and learn. If that's the case, by all means go for it.
In any case, performance shouldn't be an issue. You'd be adding an extra layer, so obviously there will be some overhead, but whether that overhead will be significant or not depends entirely on your implementation. If your REST API is the single endpoint, then it will probably be a good idea to also be the one place where caching happens. And not just server side caching, a REST API makes browser caching a bit more easier to exploit, and if you get it right, the overall performance of your application may increase, comparing to a non REST approach.
tl;dr: Don't build stuff that don't have an actual purpose (unless you're learning).
Best Answer
Your data layer should be giving you domain objects, not data transfer objects.
The database query would return
Userclass instances which class houses the domain logic. Your business service that is calling the data layer should be where you do whatever steps that are needed for your use case, such as calling multiple data access objects and obtaining all necessary domain information, invoking all appropriate business functions and finally mapping that data into your data transfer object for the UI rendering process.There are use cases where your data layer may return value objects that may not necessarily be entities as they are stored in the datastore. For example, if you have a table with a large number of columns but you are only interested in a small subset of the columns or a specific view across several entities, you may have your ORM return you a list of instantiated objects that aren't managed entities. These value objects are often immutable but aren't necessarily required to be.