Het is voor leveranciers van producten bijna onmogelijk om voor ieder platform mobiele applicaties te maken. Natuurlijk kun je dan als leverancier zorgen voor een goede responsieve mobiele website. Het nadeel van deze manier is dat je de capaciteiten en mogelijkheden van een mobiel device niet volledig uit nut.
Daarom zijn er ook leveranciers die hun backoffice via API’s beschikbaar stellen aan de wereld. Meestal wil je dat niet zonder pardon doen en wil je er als leverancier wellicht geld aan verdienen. Dus je wil een Developer portal maken met verschillende groepen, help pagina’s, voorbeeldcode, monitoring, issue lijst, FAQ, maar ook malafide gebruikers/applicaties blacklisten. Kortom het vergt meer dan even het beschikbaar stellen van een paar webservicesje.
Enige tijd geleden had ik ook zo’n droom. Ik wilde voor de SDN een evaluatie app maken. Bezoekers van een SDN event kunnen dan mobiel een evaluatie formulier invullen. Deze evaluatie data wordt in een data store op Azure bewaard. Uiteraard wil ik niet mijn tokens/connectionstrings/passwords etc in mijn mobiele apps opslaan. En aangezien ik niet voor elk device zelf een applicatie kan schrijven, deze gegevens delen met wildvreemde developers.
Dus bedacht ik dat ik een aantal Webapi services beschikbaar moest stellen. Maar zoals hierboven genoemd, had ik behoefte aan eer developers portal om mijn services uit te leggen en wat ze opleveren. Dat is veel werk voor zo’n API als dit. Dit is mijn landingspagina nu; http://sdnevalapp.azurewebsites.net/.
Gelukkig is daar een oplossing voor op het Azure platform. De API management service (documentatie site).
Als je de service gemaakt hebt, dan is er een aparte portal (https://marcelmeijer.portal.azure-api.net/admin) waar je alle instellingen doet, waar je de metrics van je API ziet, de applicaties die aangemeld zijn, welke API het vaakst aangeroepen wordt etc.
Bij de settings kun je dan de webservices beschikbaar stellen. De verschillende operaties, welke http verb, welke responses er verwacht kunnen worden, welke URL, omschrijving en helpteksten.
De URL naar de bron services kan ook on-premises gehost worden. Uiteraard is het dan wel verstandig om de endpoints op deze URL te beveiligen met een Certificaten, UserName/Password combinatie of via OAuth.
Dit is de management portal voor de beheerder van de API(https://marcelmeijer.portal.azure-api.net/admin), voor de ontwikkelaars is er een aparte portal (https://marcelmeijer.portal.azure-api.net/). Deze kan tot op zekere hoogte ook gestyled en aangepast worden.
Deze Developer portal is redelijk compleet. Alle genoemde zaken zijn hier wel te vinden.
Zo is er een handig overzicht van de beschikbare API’s.
Van de beschikbare API kun je de beschikbare endpoints zien. Je ziet dan de omschrijving en de URL om API aan te spreken. Om het endpoint te gebruiken moet je een subscription key meegeven. Het hele idee van deze portal is dan ook om gebruik te reguleren en met behulp van de subscription key is de API per applicatie/ontwikkelaar apart. Aangezien de endpoints aan de basis beveiligd zijn met Certificaten, Username/Passwords of via OAuth, heeft het geen zin om rechtstreeks naar de bron te gaan.
Op deze Developer portal kun je API methode ook uitproberen en de verschillende gedefinieerde HTTP acties uitvoeren. Je krijgt dan de trace en het resultaat te zien.
Helemaal onderaan de pagina kun je per programmeertaal voorbeeldcode krijgen. Alles om de ‘klanten’ van je API te ondersteunen en te helpen.
Zoals ik in het begin al zei, het beschikbaar stellen van een API is een maar om er een hele developer portal bij te maken is twee. Door deze Azure service kun je je richten op het echte leuke en belangrijkste van de API, de functionaliteit.
Waarom zou je het zelf doen, als je gebruik kunt maken van de expertise van andere. “You can reach further while standing on the shoulders of giants”
