Consuming external data using CORS Preflight Requests
When integrating external APIs, whether developed by Modyo, a user, or a third-party, we must take into account the cross-origin resource sharing or more commonly called CORS.
For the most part, they are automatic requests performed by the browser using the OPTIONS method. They are performed automatically when the browser detects a series of patterns and needs to validate a request using a preflight request to the server.
A web developer can also make a request that includes a preflight request. The OPTIONS method can also guide us to understand what will happen or inform us of possible integration problems by reading the response headers of this request, which are:
This header returns a boolean that informs us if credentials can be sent in the actual request.
They are the methods accepted by the requested endpoint.
They are the headers accepted by the requested endpoint.
Now let's talk about important headers in the service request. When we make a request we not only send the data that we inject in the Axios or jQuery request, we also send headers that the browser adds to these requests.
Indicates the origin from where the query is being made and only contemplates the URI, that is, it does not include the path from which the call is made. More Information
Access-Control-Request-Method and Access-Control-Request-Headers
When a request is made that requires a preflight request these headers are added to the automatically requested OPTIONS method to validate that the headers can go in the method to be called Access-Control-Request-Method announces the method to be called, Access-Control-Request-Headers announces the additional headers that will go in the final request.
Now let's talk about important headers in the service response. When we receive the response from a service, the browser uses a lot of headers to give permissions to the front end what to use and what not to use. We have several important headers in this section; most of them are available in Mozilla documentation but let's focus on the important ones for integration:
This header defines from where the api can be consulted, that is to say, when we send the request automatically this defines an origin in the headers and if this origin is accepted by the api this must in the response return the same origin or in its defect a wildcard *, the origin is unique in the response that is to say it is not accepted to receive a list of origins, the api must be in charge to return the same one from which it was consulted or a * to inform that the API is public and can be consulted from any origin. More information
This header indicates when I should request the verification or preflight request of this API again and defines in seconds this delta. More information
By combining all these headers and configurations, we can tailor with the highest degree of granularity our documents to unlock the potential of CORS and Preflight requests.