We are working on API's that call other API's that will inevitably retrieves/update a system of record like an SQL, MySQL or other database. Sometimes we'll have 3/4 layers of API's before the SOR is hit.
Normally I would use a repository class when executing functions against a system of record directly via Entity Framework or ADO.NET etc.
In this case, we don't interact with a SOR directly, but instead through another API.
Should this logic sit in the service rather than the repository?
Rather, is there any real benefit to separating this code into a repository class?
To my knowledge, a repository class should contain no business logic.
The purpose or main benefit of a repository to me is the ability to decouple the DAL from the rest of the code, e.g. when swapping between e.g. a SQL and MySQL database.