Y
Y
yalex14422015-10-27 22:05:05
symfony
yalex1442, 2015-10-27 22:05:05

What is the best way to implement receiving data from a third-party API?

I'm starting to study OOP, SF2 frameworks in particular.
The question arose of how to implement the functionality more correctly
. There is a Bundle in which controllers respond to user http requests.
What is the correct way to access a third-party API (instagram), write all the logic of api requests directly in the http controller, create a new controller with API methods put into it, or a new bundle for this?
How common?
And they also say that editing the library's composer directly by changing the code in the vendor is not good, how to add new functionality?
UPD:
I use this oneto contact instagram, but there is no function for returning results from several API requests, for example, the maximum number of photos in one method call is 33, (API limit), in order to immediately return, for example, 100 photos, you have to fence something similar in the controller

while (count($media)<100){$result+=$obj->get_media();}

Therefore, the question arose of how to add new functionality to the class.
how about creating a child class with additional methods?
regarding the creation of a service, as I understand from the documentation , a service is a
class located in the controllers directory, with methods that returns data, and there are no special restrictions on its implementation?
i.e., is it more correct to describe a subclass with additional methods that inherits the parent composer library in the service?
Regarding the repository
If the service returns an array of Entity Class photos with properties (upload date, dimensions, people in the photo, etc.), will it be some kind of repository?

Answer the question

In order to leave comments, you need to log in

2 answer(s)
S
Sergey, 2015-10-27
@yalex1442

I will skip my tirade about bundles within a single application (there should be only one bundle - AppBundle, the rest is only needed for reusable things. If you cannot reuse your solution, then there is no point in locking it in a bundle), I will focus on controllers.
As you wrote, controllers are supposed to handle HTTP requests, so let them do that. They take a request, take and process the data, ask the services to do something (and do not do it themselves) and then spit out the result of the work of these services.
The Instagram API is a data store and nothing more. To work with repositories, there is a "repository" pattern. That is, we are making a small service that will work with the API, and the rest of the code does not care where this data comes from. If you need to add API response caching, you can create a decorator service, and so on. Well, for interacting with the API itself, there is a sea of ​​​​ready-made solutions, up to ready-made clients for Instagram. Your task is to close the whole thing with a facade, a beautiful interface through which your tasks are solved simply. Thus, we will hide all the complexity of getting pictures, etc. for the application.
In short, the main idea, since it’s shit to code (and you can’t do without it at the training stage), then let this matter be isolated behind a beautiful interface, so that later it could be corrected and the changes would not affect the entire application.
It would also be nice to practice TDD, but that's if time permits. In general, I strongly recommend switching to the practice of TDD (read Kent Beck on this topic).
Everything in vendor should remain intact. If you want to extend the functionality you have to wrap the other's thing in your own, or implement the interfaces provided by the other's thing... well, in short, you can extend it by decorating and... in the case of bad libraries, inheritance. Well, another option is pull requests, but this is only if you are sure that this functionality is needed not only by you.

A
Alexey Pavlov, 2015-10-27
@lexxpavlov

>What is the best way to access a third-party API ? It's
best to make a service that will have your connection code with-anything. And in the application itself, use the service as a high-level element. If you see that this code may be used in different projects in the future, then it makes sense to put it in a separate bundle. I don't see much point in splitting one project into different bundles (unless specifically to make them very loosely coupled).
Read my answer in another question.
> how to add new functionality?
Fork lib, add your code, and connect your fork. This is a general rule, not just for Symfony, and not just for composer. Otherwise, if the library author releases a new version (new feature or bug fix), then your change will conflict with the new version of the lib.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question