One of the features introduced with Apprenda 3.5 was support for REST authentication; essentially we exposed a REST endpoint to authenticate into the platform using either JSON or XML.
This in itself enables a huge number of new clients that can call services hosted on the platform and take advantage of all of the great features that the platform provides for high availability and service scalability among others in order to offer a world class hosting experience for your backend web services.
A good example of this is a Mobile client. With the proliferation of mobile devices from cellphones to tablets in the last few years, having a mobile strategy for your applications is becoming a top priority and leveraging Apprenda to host your backend web services will tremendously help with this challenge.
On a high level, the authentication dance works like this:
First, a client makes a request to establish a session on the platform by providing a set of credentials; next those credentials are validated and verified by the server in exchange of establishing a session. If a session is successfully established, all subsequent requests from the client should include an identifier so that the platform can verify that the call is from an authenticated source.
There are a few ways to make this work in Apprenda. You have the option of communicating with the authentication endpoint via JSON or XML so the URLs used vary respectively:
Once you’ve decided the format that you will communicate with, the next step is constructing the proper payload to establish a session, the following is an example of a JSON payload:
As you can see from the image above, we are constructing a POST request where the body of the request includes the credentials needed to establish a session. The important things to note, are the url we are posting to, as well as the format of the request Body.
If your request is successful, you should receive a response like the one shown above, otherwise it will look more like the one below.
Once you have established a proper session with the platform, all you need to do is to include your session identifier with subsequent requests. This allows the platform to know who the caller is without the need to specify credentials on every call.
You have 2 options for identifying your requests with the platform; you can specify your session identifier as a request parameter or as a request header based on your preferences. The following is an example of both:
Pulling it all together through a concrete example: Now that we understand how the authentication dance works, let’s take a look at a concrete example. The attached example is a simple Hello world service that exposes a REST endpoint. However you will only be able to call it if you are authenticated to the platform.
First we will try to call the service without authentication so that we can see that the platform returns the proper 401 error code indicating that the user is not authorized to make the call.
Now, we will modify the call so that it establishes a session first and then makes the same call again using a request parameter to indicate the session identifier.
As you can see from the above image, this time we are receiving the expected “Hello world” result from the service indicating that the user making the request was verified as trusted and permitted access to the service.
Obviously all we’ve shown so far is an extremely simplistic exercise, but it is really easy to see how this can easily be extrapolated into a real application service with a real mobile client.
In the coming months, we will continue to improve on this functionality to offer more restful services to leverage all of the functionality of the platform but we’d love to hear your thoughts and hear what you are planning on doing.
Cheers and REST assure that a lot more is coming 😉