Repositories can manipulate and "transform" data?

Question

I’m implementing two video service Apis (Youtube and Vimeo), and because it’s a layer of data, I thought it was ideal to create repositories for each one, with the API being the "source" of the data.

something like:

class YoutubeApiRepository implements VideoRepositoryContract
{
    public function search(string $term): ?array
    {
        $YoutubeApi = new YoutubeApi;
        return $YoutubeApi->findVideos('baby shark');
        // return Google_Service_YouTube_SearchResult
    }
}

class VimeoApiRepository implements VideoRepositoryContract
{
    public function search(string $term): ?array
    {
        $VideoApi = new VimeoApiClient;
        return $VideoApi->findAllByTerm('baby shark')
        // return []
    }
}

The "problem" is that each API has a return in a different format...

1 - Would it be wrong for a Repository to iterate and manipulate the results of these Apis to standardize them? or it would be better if attached to another class "transformative"?

2 - In the case of a transformative class, an interface and a concrete implementation are created for each repository, such as would it be possible to standardize the past parameters? for example, Youtube returns an instance of the Object Google_Service_YouTube_SearchResult, already the Vimeo returns a Array ""and any data could be passed to the transformer...

Example of the class "transformer":

Interface VideoResponseTransformer
{
    public function transform($rawData): array
}

class YoutubeResponseTransformer implements VideoResponseTransformer
{
    public function transform($rawData) //Google_Service_YouTube_SearchResult
    {
        foreach ($rawData as $video) {
            ....
        }
   }
}

class VimeoResponseTransformer implements VideoResponseTransformer
{
    public function transform($rawData) //Array
    {
        foreach ($rawData as $video) {
            ....
        }
    }
}

Answer 1

1 - It would be wrong to iterate and manipulate the results of these API to standardize them? or would it be better if attached to another class "transformer"?

Why would that be wrong? Your initial thinking is correct, you have created an interface that abstracts communication with the various video services you will consume. You treated these services as repositories, and there’s no problem with that, but your primary goal in this approach is abstract access to the various video services that exist around.

From there you can create a Factory to achieve the correct implementation according to the type of service you will consume. You can also add support to other services at any time without the need to change something in existing services.

2 - In the case of a transformer class, an interface is created and a concrete implementation for each repository, as would be possible standardize past parameters? for example, Youtube returns a instance of the Google_service_youtube_searchresult Object, already the Vimeo returns a "raw" array, and any data could be passed to the transformer...

I think you’ve given the answer on that point. Each platform will treat the data differently, this is an implementation detail and not a usage detail, and for this reason you do not need to create an interface to try to unify this. Unless you can find a pattern to build your interface, and if this isn’t too costly for you, I suggest you treat the data transformation as a responsibility for implementing each repository.

About the @Virgilio comment, if you want to perform a dependency injection per constructor it will be necessary for your classes to implement a specific interface for each one. You would have a IYoutubeRepository and a IVimeoRepository for example, but from what I understood of your question, your idea is really to be able to replace and decouple the implementations of different platforms.

If this is the case, you can use a Factory interface like IVideoRepositoryFactory which can receive the platform (viemo, youtube, etc.) as a parameter and return a correct instance of IVideoRepositoryContract. If you decide to go this way, the dependency injection would no longer be specifically from the platform, and you would start injecting Factory itself. Will depend on your implementation and need.

I was just wondering what the real advantage of Factory would be, since she would have to return a Repository too, can create an example?

Factory is a standard that solves problems to create objects. It does not conflict with the Dependency Inversion standard, whose main objective is to decrease the coupling between the components of your system. They solve different problems and can be used together, and your case is a good example of this. You have a service that searches for videos, which can have several implementations according to each platform. Who will consume this service need not worry about finding which is the correct implementation for the platform he is looking for, and to solve this problem you can utilize a factory. Below is a pseudo-code about this and a Stack exchange software Engineering link with a similar discussion.

class Video { }

interface IVideoFinder{
    Video search(string url);
}

// várias implementações YoutubeFinder, VimeoFinder, DailyMotionFinder...

interface IVideoFactory {
    VideoFinder create(string url);
}

class VideoFactory : IVideoFactory {
    VideoFinder create(string url) {
    // Retorna o VideoFinder correto de acordo com a URL da plataforma
    }
}

class Consumer{
    Consumer(IVideoFactory videoFactory) { }
    DoSomething(string url) {
        var video = videoFactory.create(url).search(url)
        // Fazer algo com as informações de video, independente da plataforma...
    }
}