Have you ever scanned a document into your phone and uploaded it to Dropbox? How often do you log in to a web service via Facebook to save having to create a new account? Well, these both rely on APIs, most probably built using the architectural style of REST.
RESTful services are typically used in Web applications and it’s importance is increasing as technologies continue to share features and data via APIs. If you want to know more on REST, you can find a good blog here.
In our last blog, Jumping onto Mendix, Tom Worthington introduced the rapid application development platform ‘Mendix’. In this blog, we will talk about how you can integrate a Mendix app with any Web service that uses REST.
There is a great example of how to consume a REST service with Mendix in the ‘how-to‘ section of the Mendix Website. This uses the API from the rijksmuseum.nl to receive data and displays it in a Mendix app using GET requests. Here, however, we will be using a POST request with the Dropbox API to show how easy it can be to send data the other way.
From Mendix version 6.6.0 onwards, it is possible to consume REST services using the ‘Call REST service’ microflow action. However, as we started this project in Mendix version 6.5.1, we downloaded a module from the Mendix APP store (which is available to use in all Mendix versions 4.4.4 and above). Both methods allow developers to use any RESTful service.
Using an access token (unique to a user’s Dropbox account; there will be more on this later), requests can be made to the API to do various operations, such as listing the files and folders from the Dropbox account, creating shared links, and downloading documents. In our example, we will be using the Dropbox API to upload a document to Dropbox from Mendix.
Here we see the HTTP Request (top) and an example JSON Response (bottom) from the Dropbox API for uploading a document:
Using this information, the domain model in Mendix must be set up as shown below:
For this example, we need an entity for the document to upload. A System.FileDocument is suitable and extra attributes have been added that are needed for the request. At the moment we only require the path (the location within Dropbox to upload the document to) and the Access Token. The token is used by Dropbox to identify the account and authorise access. For this simple example, we will allow the token to be inputted directly, however, a better way to do this is to allow each user to authenticate the app with Dropbox using Oauth2. This lets the user grant access to their files without retrieving the token directly.
Other parameters can be added if required. For example, the ‘mode’ parameter could also be added to allow the option to add, overwrite or update the document in Dropbox.
We have then created a non-persistable entity to store the result and set up the rest of the domain model in the correct format for the expected response from Dropbox.
Having set up the domain model correctly, a microflow will be used to make the request. The microflow should take in a document object as the input parameter, having uploaded a document, and entered the path and access token.
A result object is created initially, that will be used in the postWithResult java action (from the rest services module) as the responseData. The document will provide the dataObject in the same java action. Before that, headers must be added for the Content-Type and Dropbox-API-Arg (providing the Dropbox folder path). The ‘addHeaderToNextRequest’ java action is useful for this purpose.
The path must be entered with a ‘/’ before each folder level. For instance, suppose there is a folder named ‘Test folder’, containing a document named ‘Test.docx’, the overall folder path would be ‘/Test folder/Test.docx’. Hence, in our example when uploading the document the path must include the name of the document being uploaded.
Finally, the dataObject and responseData are set up. The collection URL, found in the documentation of the API, is where information of what to do with the data, is being sent. This is where we add the Access Token for the user. The ‘?authorization=Bearer%20’ is a way of telling Dropbox that the token is being sent in the URL.
After this microflow is called, a page displaying the results is shown, which should contain the results object along with any the other associated entities. The document should now be present in the Dropbox account.
This example demonstrates how easy it can be to use RESTful services from Mendix, providing the domain model is set up correctly.
For documentation on all Dropbox API functions please click here.