Front end <--> API Service -> Service -> Repository -> DB
Front end: web client, mobile apps
API Service: Rest Controllers, here I use converters and dto's and call services
Service: Interfaces with implementations and they contain business logic
Repository: Repository interfaces with automatically implementations(done by spring data jpa) which contatin CRUD operations and maybe some sql queries
This's the design proposed by Spring. So you are in the "Spring's right way".
Repositories are commonly called DAOs but from the design point of view, Repository and DAO are different components with different responsabilities.
Repository pattern belongs to a higher level of abstraction. It's a domain object. Closer to the business than the DAOs.
In Spring JPA, the DAO is called EntityManager. It manages the sessions, the access to the DataSource, etc.
Translated to Spring components, your design looks similar to:
@RestController > @Service > @Repository > EntityManager
For repository' interface and implentation enhancement, look for:
- @NoRepositoryBean - BasicRepositoryBeanFactory implentations
These components allows you to decouple your "repository layer" from the Spring's implentation. At a level.
Back to your question, I would not add another abstraction layer. At least, I would not do It by the reasons exposed here. I would take profit of the Framework capabilities. I also think that a second layer will add unecessary complexity.
Note: Despite the reasoning here, as usual, the solution depends on your specific requirements.