This post is a trivia on Base64 encoding. To make a TM1 Rest API call, we’ve seen (link) that credentials are encoded in Base64 in the Authorization header key. So, I thought let’s take a little deeper look into the Base64 encoding.
It’s worthwhile to remember that Base64 is encoding and it is NOT encryption. Since the resultant string can be easily decoded – the protocol therefore needs to be https, so the confidentiality of the data is maintained between the client-server communication.
the deal with number 64
When I was introduced to using Base64 encoded strings, the 1st question that came up was: what’s the deal with number 64? Base64 algorithm takes the input string and maps it one of the 64 characters namely:
–> Capital alphabets A through Z (count of 26)
–> Lower alphabets a through z (count of 26)
–> Numbers 0 through 9 (count of 10)
–> Plus symbol + (count of 1)
–> Slash symbol / (count of 1)
There we have it: 26 + 26 + 10 + 1 + 1 = 64. This means the final Base64 encoded string will always be one of these 64 character: A-Z a-z 0-9 + /
the deal with = (equal to) sign
In my early days of using the Base64 encoded string, I wondered why sometimes I saw an = (equal to) sign and sometimes it was missing. = is not one of the 64 characters mentioned above. Despite that, it does appear occasionally and there is an interesting reason behind it.
During encoding Base64 takes 3 bytes of 8 bits each (3 X 8 = 24 bits) and replaces them with 4 bytes of 6 bits each (4 X 6 = 24 bits). If you are wondering why 6 bits … remember 2e6 = 64 (it’s difficult to show mathematical equation on this blog, therefore in words, its 2 to the power 6 = 64). It continues to work on the next 3 bytes of the input string, until there are no more characters left. Let’s work our way with few examples.
- Input string is 9 characters long. I am using input string 123456789 which is then encoded into Base64. You will see the output string as seen below. Since the input string can be equally split into block of 3 characters each, the encoded string will be 4 X 3 = 12 characters long. (I have inserted a yellow separator, to show the splits between the string).
- Input string is 8 characters long. The first 3 characters 123 are encoded, followed by 456. Lastly 2 characters remain i.e. 7 and 8. Since the input block is of only 2 characters, it will append an
=at the end, to make the output block of 4 characters.
- Input string is 7 characters long. The first 3 characters of input block 123 are encoded, followed by 456. Lastly 7 remains. Since the input now consists of only 1 character, Base64 encoding algorithm will append two equal to signs at the end, as seen in the screenshot.
- Input string is 6 characters long. The input string can be split into 2 blocks of 3 character each. Therefore the encoded string will be 4 X 2 = 8 characters long.
Why Base64 Encoding?
There are multiple constraints of REST, and one of them is Stateless i.e. client and server interactions are stateless. Therefore, every client request must contain all of the information including the authentication in itself. This information can be stored as part of the URI, query string, parameters, headers or in the body. The server uses this information to understand, process and communicate back the response to client.
In order for the API call to do its intended work, the user performing the activity must first authenticate to the TM1/PA server. There are lot of HTTP Authentication mechanisms (link), however Basic Authentication (BA) is the commonly used and simpler. In BA:
1) Credentials are combined using a : (colon) character – example username:password
This means the username and the password itself cannot contain a : (colon) character in it.
2) The credential string is then encoded using Base64. Thus necessitating the use of Base64 encoding.
Related posts on TM1/PA REST API
| Sl No | Title with brief description |
|---|---|
| 1 | TM1/PA REST API Part 1: Introduction – Getting it Right There are few things to understand before getting into the weeds of working with the TM1 REST API. This post is an absolute introduction to shed some light on the pre-requisites, for interacting with TM1 REST API. |
| 2 | TM1/PA REST API Part 2: Introduction – Get started with Postman This post introduces you to an API client – Postman, to help you get started and to dip your toes in the water, to test out the TM1 REST API functionality. |
| 3 | TM1/PA REST API Part 3: Execution – Making an API Call This post demonstrates a detailed example to make a TM1 REST API Call – specifically GET method of an HTTP request. We will see how to form the URL, put proper settings in Postman and ensure we get the result we want from TM1/PA server. |
| 4 | TM1/PA REST API Part 4: Understanding Server Response In this post, we will continue our journey in understanding the TM1 Rest API. We will understand server response, map it with the EDM structure. I will share some tricks to cutdown the payload received from the server. |
| 5 | TM1/PA REST API Part 5: Trivia on Base64 Encoding This post is a trivia on Base64 encoding. We will see the significance of number 64, why there are sometimes one or two equal to signs. |
More Reading
* Understand how Base64 encoding works (link)
* Step by step working example of Base64 encoding (link)
* Read more about Basic Authentication in Wikipedia (link).
* REST principles (link).
Ever Analytics 