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.
Best Answer
The calls to other APIs should go in the repository layer.
The service layer shouldn't care how it gets its data, no matter where that data comes from.
The job of a repository isn't communicating with a database, it's to interoperate with a data source and abstract those details from the rest of the system. It retrieves data and, just as importantly, translates that data from the source's language and layout to the service's language and layout and vice versa, be that from database tables to objects, JSON to objects, or other formats.
That's not business logic, that's data logic, and belongs separate from it.