Use Laravel to Consume APIs and Services Over HTTP

Before you can consume any service, you need to know a little. Determine where to send the requests (what URL), how it works and how to access it.

Through the question system, you can solve your doubts, but it is very important that you ask them in the right way to help you better.

The API that you will consume during the course is protected. So you will have to create your own users and clients to access their information. Here I explain how.

Do you have questions about OAuth2 and the access tokens? Do not worry, in this class I explain the different ways to obtain an access token and its characteristics.

Usually, the tokens obtained from an API usually expire after a few hours, so it is necessary to refresh or renew them to obtain a new one.

Finally, to consume any service, it is very important to know the structure of the responses that such service returns. In that way you will know how to access the information you require and even determine when there are errors or not.

Here I explain a little about the development environment that I recommend to follow the course. However, you are free to use the tools with which you feel best to follow the course.

It is time to obtain the Laravel structure, using composer, to start implementing the HTTP Client.

Here I share details of how to access the source code of the HTTP Client built during the course and how to use it.

Guzzle is a very popular and extended PHP library for making HTTP requests in a simple and intuitive way from any PHP project, which includes Laravel and your HTTP Client.

Take some notes of an additional step to follow if you are using Laravel 6.0

Let's resolve some possible confusion with the usage of Laravel Vite over Laravel Mix

It is time to prepare the environment so that the HTTP Client can work without problems. In this class, I will show the use of php artisan serve and SQLite. However, you can use the environment you prefer.

It is time to add the fields and components that we will need to store in our own database in order to consume the target API and automate the process easily.

Some useful details to keep in mind to follow all the steps in this section using Laravel 6.

Using the facilities provided by Laravel, we will generate different components that will allow building the graphical interface of the HTTP Client, easily.

The way in which the welcome view that comes by default with Laravel is used is somewhat limited in functionality. During this class, we're going to improve that, so we can easily send values to the main welcome view, along with some fixes in the visual part.

It is very important to be able to indicate to the user of the HTTP Client, the result of different operations (either success or error). During this class, you will create two components that will be used in the project layout that will allow you to properly display both error and success messages.

We will add a small button in the login form that will allow, once implemented, to log in directly with the API used by the HTTP Client.

During this class, you will create the main component of the project. This is the component that can send HTTP requests in a generic way using Guzzle from Laravel.
This will be that highly reusable component that you will have for all your other HTTP client projects.

Once the generic component is created, it is time to create the specific component that will know exactly how to make the requests in the correct way to the API that the HTTP Client is consuming.

Making use of the Laravel configuration files, we will indicate the respective configurations to the API that will be consumed. Such as base URL, and access credentials.

It is time to implement, one by one, the service methods that characterize the API that will be consumed. In this case, the method responsible for solving the way to authenticate the requests and get them authorized will be implemented.

It is time to implement the method that will correctly interpret and obtain the structure of the API responses so that they can be used with ease throughout the HTTP Client.

Although Guzzle triggers exceptions when obtaining error responses, which must be controlled differently, there are services that return errors in a different way, which makes it necessary to implement a method to identify errors properly and proceed as necessary.

It is very important to maintain the order and modularity of the project, especially to facilitate the re-use of components from other places of the HTTP Client.
During this class, we are going to invest a few minutes to improve the modularity and maintainability of the HTTP Client in Laravel, allowing us to save time later.

It is time to send your first request to the API. And it will be to obtain the list of products.

Once the list of API products is obtained, it is necessary to use that information to properly display it to the users of the HTTP Client.

It is time to send a new request. On this occasion, it will be to obtain the list of categories.

As it was done with the products, it is time to also show the list of categories in the main view. For this we will add an additional column in the main view, to show them according to the users of the HTTP Client with Laravel.

It is time to obtain the details of a specific product, from the identifier of it.

It is time to show the details obtained from a given product. This also involves building a route that allows you to obtain the product identifier, and we will also add your title to be a bit more realistic in the way the HTTP Client works with Laravel.

It is time to obtain the products of a category. For this, it is necessary to receive the identifier of the category that you want to use.

Once the products of a category have been obtained, showing them will be quite similar to what was done to show the complete list of products.

It is necessary to add a new service in charge of the whole process of obtaining access tokens (OAuth2). This service must be completely independent since the service that we already have is authenticated from already obtained tokens so it cannot be used for this purpose.

It is time to add the first capacity to the new service, able to obtain a token associated with the client. Basically, you will get an access token through the grant type called client_credentials from OAuth2.

Now that the HTTP Client is able to obtain access tokens automatically, at least initially associated with the client (client_credentials); You must automate the procurement process every time a request is sent to the API.

Each token obtained has a time duration, so it does not make sense to get a new one each time a request is sent.
During this class, you will add the ability to determine if a token is still valid or not to re-use it as much as possible.

During this class, you will be responsible for correctly generating the URL to which the user will be directed when requesting authorization to access their information and allow them to log in to the HTTP Client.

Once the HTTP Client is able to generate the URL correctly, it is time to associate it with the button so that the user is correctly directed at the moment of pressing the button.

Once the user authorizes the HTTP Client, an authorization code is obtained.
During this class, you will add the ability to obtain a valid access token from a code obtained. Basically, the grant type called authorization_code of OAuth2 will be used.

Once the HTTP Client is able to obtain a token associated with the user, after obtaining its authorization, you will be able to access its information.
During this class, you will add the ability to obtain a user's information from an associated valid token.

Because there is no way to control that an existing user or not use the button to log in, you must determine whether it is a new user or not, from its identifier in the API, to create or update your access information, as the case may be.

Finally, once the HTTP Client in Laravel is able to identify the user internally, based on the access credentials in the database, it is possible to create sessions for the users.
This is one of the most interesting functions of an HTTP Client, since sessions are being created from any user coming from the consumed API.

Just as a valid token can be obtained from an authorization code, it can also be obtained from the user's credentials (username and password). This way of obtaining an access token, corresponds to the grant type called password.

It is time to authenticate a user and create a session from the token obtained with their credentials. Of course, always using some previously implemented components.

It is important to properly control faults when trying to obtain a token with the user's credentials, making sure that only cases where the credentials have been invalid and not any other error.