It is for vendors of products very difficult to make mobile applications for every possible mobile platform. Of course by preparing and making a good responsive mobile website available will enhance your reach. Not getting the most out of the mobile devices is the downside of a mobile website.
Because of this vendors make their back-office via API’s available to the world. As a vendor you want earn some money on the usage of your API. This means you need a Developer portal where you can divide developers in groups, generate help pages, provide demo/example code, monitoring of the usage, place to get issues, FAQ, but also block or blacklist certain developers/users/applications. In short there is more needed then simple provide some webservices.
A while ago I had such a dream too. I wanted to create an evaluation app for the SDN. Attendees of a SDN event should be able to fill in a evaluation form via their mobile devices. The evaluation was stored on Azure in a datastore. Of course I did not want to store my tokens/connectionstrings/passwords etc with my mobile app. And I am not able to create a app for every platform, so I definitely did not want to share my secrets with some unknown/wild developers.
So I thought of preparing some Webapi services and expose them. But like I described above, I needed a portal to explain my services and their responses. That is a lot of work for a small API like this. This is my portal now; http://sdnevalapp.azurewebsites.net/.
After creating the service, there is a different portal (https://marcelmeijer.portal.azure-api.net/admin) to do the settings, looking at the metrics, the applications, the usage etc.
At the settings is the place to make the webservices available. The different operations, HTTP actions, the response codes, which URL, description and informational texts.
The URL to the source services can also be hosted on-premises. Of course it is smart and wise to secure the endpoints on this URL with Certificates, UserName/Password combination or with OAuth.
This was the management portal for the admin of the API(https://marcelmeijer.portal.azure-api.net/admin), for the developers there is a separate portal (https://marcelmeijer.portal.azure-api.net/). Which can be styled and changed within limits.
This Developer portal is rather complete. All the mentioned functionality can be found on it.
There is a handy overview of the available API’s.
From the available API you can see the endpoints. You see the descriptions and the URI for calling the endpoint. To use the endpoint in an application the addition of a subscription key. The whole idea of this portal is to regulate usage and with these subscription key is bound per API to an application/developer. Because the base endpoints are secured by Certificaten, Username/Passwords or with OAuth, bypassing the API management is useless.
On this Developer portal there is even a possibility to try out the API method for the different HTTP actions. The trace and the result is shown.
At the bottom of the page you can find example code for a lot of programming languages. Everything to help your ‘customers’ of your API.
As I told in the beginning of this blog, making an API available is one thing, but document/manage it is another thing. By using the Azure service you can focus on the fun and most important part of the API, the functionality.
Why develop it yourself, when you can use the expertise of others. “You can reach further while standing on the shoulders of giants”