@jmacdiarmid API resources are for returning responses from your application. They‘re essentially view presenters for your application’s models to convert them to a JSON response.
In your case, instantiating a Guzzle client and making a GET request is the basis for interacting with most external APIs. So you could move that code to a “service” class for that particular API. Don’t be too concerned about the naming; a service class is essentially just a plain ol’ PHP class that contains your logic.
So, if you were working with an API for a fictitious service called “Foo”, then you could have a “FooService” class that looks like this:
namespace App\Services;
use GuzzleHttp\Client;
class FooService
{
protected $client;
public function __construct(Client $client)
{
$this->client = $client;
}
public function getBars()
{
$response = $this->client->get('https://example.com/bars');
return json_decode($response->getBody());
}
}
You could inject this class in your controller, Artisan command, queue job or whatever, and then call its methods to get the data from the API:
class SomeController extends Controller
{
protected $foo;
public function __construct(FooService $foo)
{
$this->foo = $foo;
}
public function someAction()
{
$bars = $this->foo->getBars();
}
}
And that’s pretty much it! You now have a service class, whose only responsibility is for interacting with the API, meaning if the API changes, then your changes are constrained to that class only—all of your other consuming classes (such as the controller in the above example) won’t need any changes as the interaction with the API is constrained to the FooService only.
So long as your getBars method keeps returning the same “shape” response, then you don’t need to update any code that consumes that class and its methods.
