API Management: The next steps

In onze eerste blog zijn we ingegaan op de basics van Microsoft API Management. Hierin hebben we uitgelegd wat een API is, wat belangrijke componenten zijn en wat de uitdagingen zijn die komen kijken bij API Management. In dit tweede blog gaan we dieper in op de inrichting van API Management en hoe dit allemaal met elkaar samenhangt. We bespreken the next steps!

De volgende onderwerpen worden in dit blog behandeld:

• API’s & Operations
• Groepen
• Producten
• Subscriptions
• Policies

API’s & Operations

API’s zijn de basis van API Management. De volgende soorten API’s zijn te importeren binnen API Management.

Elke API heeft een set operaties welke afnemers kunnen gebruiken. Zoals een “Get” om data op te halen. Of “Post” om data te sturen. Een API in API Management verwijst naar een back-end service waar daadwerkelijk de aanvragen worden afgehandeld. API’s worden dus niet gehost in API Management, maar alleen de verwijzing naar een API configureer je in API Management.

De backend Service kan van alles zijn, Azure, AWS, Google Cloud of On Premises. Als het maar een service is die qua connectiviteit vanaf API management aangeroepen kan worden. Op API niveau zijn diverse zaken te configureren, zoals:

• General Settings
  • API Naam
  • Gekoppeld product
• Security
  • Authenticatie methode
• Subscription
  • Subscription vereist ja of nee
• Diagnostics
  • Kan worden weggeschreven naar Azure Monitor of Application Insight

Groepen

Binnen API Management worden Groepen gebruikt om de zichtbaarheid van producten te bepalen. Binnen API Management zijn er een aantal niet aanpasbare groepen:

• Administrators -> Alle Azure Subscription administrators zijn lid van deze groep. Leden van deze groep hebben volledige rechten binnen API Management.
• Developers -> Geauthentiseerde afnemers komen in deze groep. Leden van deze groep kunnen producten zien en deze ook aanroepen. Afhankelijk van de gekozen instelling op productniveau kan dit met of zonder Subscription.
• Guests -> Niet geauthentiseerde afnemers komen in deze groep. Zij kunnen lees toegang krijgen tot de API Portal zodat zij wel kunnen zien welke Producten en API’s er allemaal bestaan maar zij kunnen deze niet aanroepen.

Buiten deze standaard groepen is er ook de mogelijkheid om zelf API Management groepen aan te maken. Deze groepen kunnen ook gekoppeld worden aan Azure AD. Op deze manier kan je op een nog betere manier bepalen welke set aan gebruikers welke producten mag zien. Gebruikers kunnen lid zijn van meerdere groepen. Per product kan je 1 of meerdere groepen toekennen.

Producten

Producten zijn de manier waarop API’s beschikbaar worden gesteld aan afnemers. Elke API kan lid zijn van een of meerdere producten maar dit is niet verplicht. Producten kunnen open of beveiligd zijn. Open producten kunnen gebruikt worden zonder dat een afnemer zich registreert. Om toegang te krijgen tot beveiligde producten moet de afnemer zich aanmelden. Producten bevatten een duidelijk omschrijving zodat de afnemers direct kunnen zien wat voor onderliggende API’s erbij horen en welke gegevens zij hiermee kunnen opvragen. Wanneer een product klaar is om gebruikt te worden door afnemers, dan wordt deze gepubliceerd. Op productniveau wordt er bepaald als er een subscription nodig is of deze dan goedkeuring vereist van iemand in de organisatie, of dat dit automatisch wordt goedgekeurd.

Op basis van groepen wordt de zichtbaarheid van een product bepaalt. Als een afnemer lid is van de betreffende groep dan is het product zichtbaar. Een afnemer registreert zich voor een product en krijgt indien nodig een Subscription key voor een bepaald product. Dus niet voor een bepaalde API. Door verschillende producten te maken met dezelfde API’s, kun je onderscheidt maken tussen hoe snel & hoe vaak een bepaalde afnemer een API mag aanroepen. Zoals bijvoorbeeld een verdeling op basis van Goud, Zilver en Brons waarbij de afnemers van het Gouden product sneller en vaker de API’s mogen aanroepen dan de afnemers met het Bronzen product.

Subscription

Elke gebruiker moet zich registreren op het Developer Portaal alvorens zich op een product te kunnen autoriseren. De autorisatie op een product noemen we een subscription.

Hieronder wordt dit grafisch weergegeven.

1. Een gebruiker registreert zich op de API Developer Portaal. Dit kan met verschillende accounts / opties:
   • Azure Active Directory en AAD B2C, Social Accounts (Google, Facebook, Twitter en Microsoft) en Basic authentication (Username/Password)
2. De gebruiker krijgt een bevestiging van aanmelding.
3. Vervolgens logt de  gebruiker in op het Developer Portaal met username en wachtwoord.
   • Gebruiker registreert zich op een product (of meerdere).
4. API Developer portaal geeft een subscription key terug aan de gebruiker waarmee de gebruiker een API binnen dit product kan aanroepen.

Daarnaast kunnen API Publishers zelf ook Subscriptions aanmaken in de Azure Portal. Dit kan op de volgende scopes:

• API
• alle API’s.
• Standalone (niet gekoppeld aan een Developer account)

Policies

Met policies kan het gedrag van een API, Product of Operation worden aangepast zonder dat de afnemer daar iets voor hoeft te doen of zelfs vanaf te weten. Policies zijn een aantal statements die sequentieel worden nagelopen bij het aanroepen van een API. Denk hierbij aan de volgende policies:

• Converteren van de informatie in de body van XML naar json of andersom
• Rate limit, hoe vaak en hoe snel mag een bepaalde API worden aangesproken
• Verwijder specifieke Response Headers

Policies worden opgebouwd in een XML formaat.

Policies zijn toepasbaar op verschillende niveau’s:

• API Management
• Product
• API
• Operation

Voorbeeld van een rate limit op een API. Deze API heeft een limiet van 20 calls per 90 seconde. Als er meer calls worden gedaan krijgen de afnemers een 429 error terug: Too Many Requests.

 

Door gebruik te maken van Azure API Management kan je als bedrijf zowel je interne als externe API’s op een en dezelfde manier onder controle houden. Wil je hier meer over weten neem dan contact op met InSpark.