How to organize the structure of a Symfony project to interact with a third-party API?

Question

symfony

There is a deployed application on symfony/skeleton. The main task: in controllers to receive data from a third-party API (no interaction with the database).
Data are specific entities (Posts, Clients, Orders, etc.).
The essence of the question is how to organize the structure of the project? I work with symfony for the first time.
1. Can each entity be represented as a service?
For example Service/PostService.php or is it better to make it a repository? Or are there other options?
2. How to get data for such entities?
Now I have made a separate class ApiClient.php which creates a guzzle client internally and accesses a third-party api
3. How to connect the entity class with the api client?
Created a separate service ApiService.php from which services that need to receive data from api are inherited. The constructor of this class creates an ApiClient.
And in child services I can make requests to api like this: $this->api->apiMethod();
I would be very grateful if you tell me what to improve.

Answer 1

The Entity -> Repository -> Service -> Controller structure is universal and not tied to the database.
Entity is your entities (posts, clients, orders). Repositories allow you to isolate data storage logic. We create a repository for each entity, which will have a dependency on ApiClient (or rather, on the client interface) through DI. The main idea of ​​repositories is to seamlessly switch to other ways of storing / retrieving data, so you should create interfaces for them and make an implementation of these interfaces for the API. In Service we describe business logic, we use repositories. We leave controllers thin - receiving services and calling their methods. You can go further and transfer the interaction of services to special services. This is useful if you need to use this logic in other parts of the application, for example, in commands
I hope I answered all the questions. If something is unclear, please ask

Answer 2

The question is written chaotically and is not clear. What the task is being solved is not clear at all.
It is necessary to deal with the terminology "to present the entity as a service" - some kind of mess. An entity is an entity, a service is a service.
"Get data for entities" is, again, some kind of mess. Write a gateway to the apishka and load the data.
And you also need to learn how to properly name. PostService is not clear about anything the class does.
Again, the title means nothing.
Inheritance - cut out and forget like a bad dream. Instances of the API - client through DI to be delivered to those classes where it is needed.