This week marks another new chapter for me in Aeste as my task is switched to handling the storage backend of the project. I have officially taken over the project from Maisha, now my ex-colleague, who has done a great job in completing the upload/download part for Dropbox. To familiarize myself with the project, I went through the whole process of from setting up an account and uploading/downloading a file. I will explain in brief what happens here:

  1. Registering the application in Dropbox.
    • This step will give you the client ID and client secret. You would also need to set up your application redirection URL ( the destination which the user will be directed after approving  the request).
  2. Authorization
    • In your web application, there would be a link to the Authorization URL of Dropbox. The link is…. where the Client ID, redirect URI, response type, and state need to be sent in the request. Once the client approves the request, a Dropbox code will be included in the redirected URL as a ‘code’ parameter.
  3. Getting an access token
    • To be able to use Dropbox API on behalf of the user, you will need an Access Token. Using the ‘code’ value, Client ID, Client Secret, you will need to POST a request to If successful, the response would be the access token, token type and UID in JSON format. For every other APIs you might want to use, upload, download etc., you will need to include the access token as the header. It’s that simple.

Using Google Drive is a similar process as well, with some difference in request URLs, its parameters and the response.

The authorization URL of Google is Here, you would need to include a ‘scope’ parameter as well. This will determine what authority the server will obtain on the user’s account. A basic request would be scope=openid email profile In our case, we want access to the Drive account as well. Therefore, scope=openid email profile

The endpoint to obtain the access token is A successful request would return the access token, id token, token expiry and token type. ID token is something I would like to highlight. Compared to Dropbox who chose to hand you the UID just like that, Google does otherwise. The ID token is encrypted in JWT (Json Web Tokens) and you will need to crack it open to get the User ID, which is listed as ‘sub’ in the decryption, together with other useful info. There are two ways to get around this:

  1. Attach a decode module in your application. There are several open source libraries for several different languages.
  2. For simplicity purposes, you can just send a request to with the id_token that you have obtained.

Uploading a file to Drive

To upload a file to Drive, simply make a POST request to with the file info included in the header. ‘media’ is a simple upload type. The uploaded file would be untitled. A separate request would be needed to edit the file metadata.

On the other hand, there is another option to upload a file, which is through ‘multipart’ upload type. It is a POST request consisting of two parts – Metadata part and Media part. As it was my first encounter with multipart Content-type, I took some time to get it to work. The important thing I learned is that the format must be followed completely, if not you will be faced with ‘Malformed multipart body’ as the response. The ‘boundary’ must be initiated and ended properly in the request body. As I’m using Wt to send the request, the headers for metadata and media part and its body must be created manually using stringstream. A mistake i made was not having a new line after the headers.


While working on this, I spent some time at the playground, which was a great learning place and definitely indispensable for beginners like me.