HTTP and HTTPS with REST API

Hello

The HTTP protocol allows you to obtain resources, such as HTML documents. It is the basis of any data exchange on the Web and a client-server protocol, meaning that requests are initiated by the recipient, usually a Web browser.

REST APIs take advantage of this protocol to exchange messages between client and server. This makes REST APIs fast, lightweight, and flexible. REST APIs use the HTTP verbs GET, POST, PUT, DELETE, and others to indicate the actions they want to perform.

When we make a call to a RESt API, what actually happens is an HTTP call. The API receives this call and according to the requested verb and path, the API performs the desired action. In the case of the Iris implementation we can see this clearly in the URLMap definition area:

XData UrlMap
{
<Routes>
        <Route Url="/cliente" Method="POST" Call="Incluir"  Cors="true"/>
        <Route Url="/cliente/:chave" Method="PUT" Call="Alterar"  Cors="true"/>
        <Route Url="/cliente/:chave" Method="DELETE" Call="Deletar"  Cors="true"/>
        <Route Url="/cliente/:chave" Method="GET" Call="Pesquisar"  Cors="true"/>
        <Route Url="/cliente" Method="GET" Call="Listar"  Cors="true"/>
    </Routes>
}

Notice that we have the path (Url) and the verb (Method) defined for each call (Call). Thus, the code that meets the API knows what it should do.

When we use HTTP, we have to keep in mind that the data we are traveling with is open, that is, it is not protected by any type of encryption or security. Anyone who is able to capture the data packet being trafficked will be able to see what is being transferred between the client and the server.

Let's, for example, look at the call to a REST API that uses Basic Authentication. For this we will use Postman as a client, accessing a REST API in Iris and we will use TCPTrace to forward the data and visualize what has trafficked.

First let's publish our API. Let's use the same API as in article https://community.intersystems.com/post/using-rest-api-flask-and-iam-intersystems-iris-part-1-rest-api

Just follow the guidelines and use the code that the article provides to have our API published.

Now let's turn on TCPTrace. It can be obtained easily on the web. You can also use any other software that forwards TCP/IP packets:

Configure TCPTrace to listen on port 8080 and divert to the server that will service the request on port 80, which is the default port of the HTTP protocol:

Opening Postman we will consume our API, but we will change our call address. We are not going to call the destination server, but the server where TCPTrace is listening for the calls:

See that we performed a GET and received a STATUS code 200 (success). We use authentication to access our API and receive the packet as a response.

Now let's see TCPTrace:

We can check everything that has traveled is visible. The authentication credentials are in the Authorization header  as a Base64 string:

Everything that has trafficked is accessible and visible to those who collected the data. This can become potentially dangerous when we transfer sensitive data. But how can we solve the case? We can enable HTTPS on our web server, which puts a layer of encryption on our communication.

Enabling HTTPS requires the installation of an SSL certificate on the web server. There are authenticating entities that issue certificates that are valid and recognized on the web, or we can use the so-called self-signed certificates. Self-signed certificates are not automatically recognized, and it is not always a recommended security solution, so always check which type of certificate you should use. In our article we will use a self-signed certificate.

Certificate installation and HTTP activation depends on your web server. Browse the appropriate documentation and see how to create and install the certificate and enable HTTPS.

For this article we are using IIS which has available an option to create a self-signed certificate.

Once HTTPS is active, let's test our web server. It serves HTTPS requests on standard port 443, or by entering the "https" protocol in the URL call.

Let's do a test. Open your browser and access the web server with https:

Notice that the browser has informed you that your connection is not private. This happens because of the self-signed certificate that is not automatically recognized, Click Advanced:

Now the browser has completed the information by stating that the certificate is not trusted. This happens because he has no way to confirm if this certificate belongs to who he says he is because he is self-signed. Click Continue and see the page that was called:

So far so good. We already have our web server responding to HTTPS requests. Now let's go back to Postman and make a call to our API using HTTPS. For this we will change the call in Postman to use https instead of http. In this moment we go straight to the server, and not to TCPTrace. Remember to enter the address of your web server then:

Notice that we receive the same response as the one given by HTTP, only we have an information icon next to the HTTP Status. Click on the icon and you will see an information bubble. It informs us of the status of the certificate and some security data.

Now let's route our call to traffic through TCPTrace. Let's activate and configure our app:

Note we are now using the HTTPS port 443 to the Destination. Click OK and TCPTrace will start listening for the requests:

Go back to Postman and change the call by saying that you now want to access the TCPTrace address on port 8443 (the one configured to listen for requests). Click Send and see the request responding:

Note that nothing has changed from the last call. But now it ran for TCPTrace. Let's see what was logged into the application?

We were unable to view any information because the data trafficked was then encrypted. In my TCPTrace options click on View and then on Show NULLS and see what TCPTrace actually collected:

Thus, without any change in our REST API, we have included an encryption layer in the traffic when using HTTPS, increasing the security of information in our communication.

See you next time!