Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

panthro's avatar

Using API Resources with Repository / Service pattern?

I have a repository layer that sits above my eloquent, these repositories are accessed via services from controllers...

  • Controller Entry Point (either an API controller or a web controller)
  • Services
  • Repositories
  • Eloquent
  • Database

I've just been reading about API resources, which I think are used to return a JSON response and means that you can hide your database structure / not effect the API if your database structure changes as you can transform responses.

Are responses from API routes not just JSON anyway, so why do you need an API resource if you don't need to transform the data? Won't the API routes just convert the responses to JSON anyway?

How would API resources fit in with my setup above? Would you transform it just in the API controller and not the web controller - or would it fit elsewhere?

0 likes
5 replies
ApolloBLN's avatar

I have the same question, don't get why and how to use resources with repositories

1 like
kalemdzievski's avatar

First of all, API resources (or so called "Transformers") are great! Highly recommend them for API.

Yes, you are right, if you return the data from the repository (or even model) to response, Laravel will automatically transform it to JSON, so basically you have the functionality already.

But, API resources are more than that. You get to control what is returned in your API response, and how its returned. In other words you get to control, what the user will see. And all of that in one place. One class. This is very imporant.

Let me share with u few examples from experience. For reference, if not using API resources i will refer as "default way".

  • Date formatting. You don't need to format dates when using them within the code, but when user sees them, they probably need to be formated.
  • Timezones. You may not need to transform dates(datetimes) when using them within the code, but when user sees them, they probably need to be transformed into timezone.
  • Encodings, other formatings, stuff like that, that you only need for user representation.
  • Relations. With the default way (not using API resources), i think that every loaded relation will also be included in your response. This is not ideal. The response might get heavy this way and you will be returning data that is not needed in the response. Plus now you need to hide columns for them (if any).
  • Nested resources. However, if you do need to return a relation (as nested object) in your response, you can easily control this with API resources. You can define which ones should be included and even use their API resources to transform them.
  • If you want to add some additional info in the response, that the model does not have. For example statistics array for the user.

Now, you may say that, all of this can be done without the API resources, and yes, it can be done. But, it will be done (coded) in different places in the code (different classes maybe). For me, personally, that might not be ideal in terms of organization of code or debugging.

How would API resources fit in your setup? Well i would recommend implementing them in the API controller. That way, they won't affect any business logic and they will be used only for API response.

At the company where I work, we've been using API resources for few years now, and they've been really helpful.

Hope this helps. Let me know if you have more questions.

1 like
martinbean's avatar

@panthro API resources are used for transforming models to a JSON representation, yes. I don’t really understand your question though because you touch on the answer in your post.

return a JSON response and means that you can hide your database structure / not effect the API if your database structure changes as you can transform responses.

This is exactly it. You can control what columns are exposed via your API.

Are responses from API routes not just JSON anyway

Yes, but if you don’t transform the model then it’s just going to return the “default” JSON representation, which may include columns you don’t want exposed, and won’t allow you to keep API responses consistent if you change the name of a column in your database.

Would you transform it just in the API controller and not the web controller

Why would you use an API resource in a web controller? You’ve understood API resources are for returning JSON representations of a model, so why would a web controller return JSON? Surely your web controllers are returning HTML views?

sman's avatar

If you are getting data from sources you don't control, such as 3rd party API's, then it's pretty useful imo. Bottom line is it helps keep all your returned data consistent and fully customizable in one location.

This article explains the why and how of it.

https://medium.com/@jeffochoa/consuming-third-pary-apis-with-laravel-resources-c13a0c7dc945

They are returning it in repository class in their example. I have a project that accesses several different API's. I have a separate repository for each API and it doesn't make sense to put the resource in the controller in that case. So I also put it in the repository because even if I change the API later on, and therefore the repository, the Resource will always be tied to the repository.

I can still combine repositories in the service layer as they are still arrays until you echo or return from controller. Worst case I might have to add another general resource in the controller.

Putting it in the controller makes more sense if you are doing it by table instead of by API.

Please or to participate in this conversation.