Before closing this chapter, we would like to touch upon one of the simplest tools we have to secure communication between client and server, or between different Microservices while communicating through REST. The tool we are referring to here is the secured HTTPS protocol. It is almost always recommended to use HTTPS for production-level REST communications where data is of importance. Let's take a look at what HTTPS is and how it helps.

HTTP stands for Hypertext Transfer Protocol, over which most communication happens on the internet. HTTPS can be thought of as HTTP + Security, or HTTP over SSL (Secure Socket Layer) or TLS (Transport Layer Security, the successor of SSL).

The oldest and most trustworthy form of data security is encryption, which can be implemented in two ways: a symmetric manner or an asymmetric manner. Asymmetric encryption is implemented using a single key, for both the encryption and decryption processes. To implement asymmetric encryption, we use a set of keys, namely a public and a private key. The data encrypted through one key can be decrypted through the other. Asymmetric communication is slightly slower due to the additional complexity. 

Another important aspect we need to understand is certificates. There are various certification authorities that provide certificates for domains. Whenever you visit an HTTPS link, you see a small lock icon on the left side of the address bar; if you click on this icon, you will see certificate details, which include the authenticity of the website and the authority that is providing this certificate. If you click a spam link by accident, validating the certificate might help you save yourself. 

So how can https make sure two services communicate in a secured manner? Let's take a step-by-step look at what happens behind the scenes when we use HTTPS-supported URLs:

1. When a call is made through the HTTPS URL, the server treats this as a special request that needs security. 
2. The server returns a certificate to the calling service or browser, along with a public key. Note that the server will never share a private key.

3. The calling service or browser authenticates the certificate and makes sure the communication is being done with the correct server. 
4. The calling service or browser generates a symmetric key, encrypts it using the public key it received from the server, and sends the encrypted key to the server. 
5. The server receives the encrypted symmetric key and decrypts it using its private key. 
6. Both the client and server have a symmetric key that was transferred securely. Now both parties use this symmetric key for the rest of the communication.

We can see the usage of HTTPS adds a very strong layer of security for communications happening over the internet.