Wat is een API? Application programming interfaces uitgelegd

API staat voor Application Programming Interface, een concept dat overal van toepassing is, van opdrachtregelprogramma's tot enterprise Java-code tot Ruby on Rails-webapps. Een API is een manier om programmatisch te communiceren met een afzonderlijke softwarecomponent of bron.

Tenzij je elke regel code helemaal opnieuw schrijft, zul je interactie hebben met externe softwarecomponenten, elk met zijn eigen API. Zelfs als u iets helemaal opnieuw schrijft, heeft een goed ontworpen softwaretoepassing interne API's om code te organiseren en componenten herbruikbaarder te maken. En er zijn talloze openbare API's waarmee u gebruik kunt maken van functionaliteit die elders op internet is ontwikkeld.

Wat is een API?

Een API wordt gedefinieerd als een specificatie van mogelijke interacties met een softwarecomponent. Wat houdt dat precies in? Stel je voor dat een auto een softwarecomponent is. De API zou informatie bevatten over wat het kan doen - accelereren, remmen, de radio aanzetten, enz. Het zou ook informatie bevatten over hoe je het die dingen zou kunnen laten doen. Om bijvoorbeeld te accelereren, zet je je voet op het gaspedaal en duw je.

De API hoeft niet uit te leggen wat er in de motor gebeurt als je het gaspedaal intrapt. Daarom kun je, als je hebt leren autorijden met een verbrandingsmotor, achter het stuur van een elektrische auto kruipen zonder dat je een hele reeks nieuwe vaardigheden hoeft te leren. Het wat en hoe informatie komt samen in de API- definitie , die abstract is en los staat van de auto zelf.

Een ding om in gedachten te houden is dat de naam van sommige API's vaak wordt gebruikt om te verwijzen naar zowel de specificatie van de interacties als naar de daadwerkelijke softwarecomponent waarmee u communiceert. De uitdrukking 'Twitter API' verwijst bijvoorbeeld niet alleen naar de set regels voor programmatische interactie met Twitter, maar wordt in het algemeen begrepen als datgene waarmee je communiceert, zoals in 'We doen analyse van de tweets die we hebben gekregen van de Twitter API. "

API als abstractielaag

Als het om software gaat, zijn API's letterlijk overal. API's gaan hand in hand met een van de meest fundamentele concepten in de informatica: abstractie. Abstractie is slechts een manier om de complexiteit van een systeem te ordenen, zodat gecompliceerde acties op een eenvoudige manier kunnen worden afgehandeld. Denk aan deze abstractie als die Amazon Dash Buttons, de op batterijen werkende printplaten met drukknoppen die je kunt gebruiken om nietjes bij Amazon te bestellen. Dit is hoe ze eruit zien:

U bestelt een Dash Button bij Amazon en gebruikt een app op uw smartphone om deze te koppelen aan uw wifi-netwerk, uw Amazon-account en een product, bijvoorbeeld uw favoriete merk keukenpapier. Als u vervolgens meer papieren handdoeken wilt bestellen, drukt u gewoon op de knop. De Dash-knop maakt verbinding met internet en stuurt een bericht om een ​​bestelling op uw account te plaatsen. Een paar dagen later komen er papieren handdoeken voor de deur.

Net als een API is de Dash Button een heerlijk eenvoudige interface die allerlei soorten complexiteit achter de schermen verbergt. De ID van het product dat u heeft besteld, moet uit een database worden gehaald. Uw afleveradres moet van uw account worden gehaald. Het dichtstbijzijnde afhandelingscentrum dat uw papieren handdoeken in voorraad heeft, moet worden bepaald en vervolgens op de hoogte worden gebracht om een ​​artikel uit de beschikbare voorraad te verwijderen en in te pakken. Ten slotte moet het pakket door een combinatie van vliegtuigen, vrachtwagens en bestelwagens worden gestuurd, samen met andere pakketten op een manier die ervoor zorgt dat alle pakketten hun bestemming efficiënt bereiken.

Stel je nu voor dat je al deze dingen als klant moest coördineren. U zou nooit papieren handdoeken bestellen omdat het te ingewikkeld en tijdrovend is en u betere dingen te doen heeft. Gelukkig wordt de hele beproeving van je weggenomen. Er is een lange, onderling verbonden ketting van computersystemen en menselijke processen waardoor die papieren handdoeken voor de deur verschijnen, maar het enige waar je aan hoeft te denken is op een knop drukken.

Dit is wat API's zijn voor programmeurs. Ze vergen een overweldigende hoeveelheid complexiteit en definiëren een relatief eenvoudige reeks interacties die u kunt gebruiken in plaats van alles zelf te doen. In elk softwareproject gebruikt u waarschijnlijk tientallen, zo niet honderden API's rechtstreeks, en elk van die API's is afhankelijk van andere API's, enzovoort.

Openbare API's en API-integratie

API's zijn een al lang bestaand concept in computerprogrammering en maken al jaren deel uit van de toolsets van ontwikkelaars. Traditioneel werden API's gebruikt om codecomponenten te verbinden die op dezelfde machine werden uitgevoerd. Met de opkomst van alomtegenwoordige netwerken zijn er steeds meer openbare API's, ook wel open API's genoemd, beschikbaar gekomen. Openbare API's zijn naar buiten gericht en toegankelijk via internet, zodat u code kunt schrijven die online interactie heeft met de code van andere leveranciers; dit proces staat bekend als API-integratie.

Met dit soort codemashups kunnen gebruikers functionaliteit van verschillende leveranciers op hun eigen systemen combineren. Als u bijvoorbeeld de marketingautomatiseringssoftware Marketo gebruikt, kunt u uw gegevens daar synchroniseren met Salesforce CRM-functionaliteit.

"Open" of "openbaar" mag in deze context niet worden geïnterpreteerd als "gratis". U moet nog steeds een Marketo- en Salesforce-klant zijn om dit te laten werken. Maar de beschikbaarheid van deze API's maakt integratie een veel eenvoudiger proces dan het anders zou zijn. ( heeft een geweldige lijst met openbare API's die u moet kennen.)

Webservices en API's

U herinnert zich misschien de term w eb services uit het begin van de jaren 00 en denkt dat het idee van een open API ongeveer hetzelfde klinkt. In feite is een webservice een specifiek soort open API, een die voldoet aan een vrij rigide set specificaties, waaronder de specificatie in Web Services Description Language (WSDL), een XML-variant.

Webservices waren bedoeld om te worden gebruikt als onderdeel van een servicegeoriënteerde architectuur (SOA). Zoals de Nordic APIs-blog uitlegt, gaf dat webservices een slechte naam, omdat SOA's hun potentieel nooit helemaal waarmaakten. Vooruitgang in de technieken die worden gebruikt voor service-to-service-communicatie - met name lichtere, flexibelere REST - hebben webservices ook enigszins achtergelaten in de wereld van openbare API's.

REST API's

Webservices zijn oorspronkelijk ontworpen om te communiceren met SOAP (Simple Object Access Protocol), een berichtenprotocol dat XML-documenten via HTTP verzendt. Tegenwoordig gebruiken de meeste webgebaseerde API's REST - Representational State Transfer - als architecturale stijl.

REST werd formeel geïntroduceerd door Roy Fielding in zijn proefschrift in 2000. Het is een set van architectonische componenten, ontwerpprincipes en interacties die worden gebruikt voor het bouwen van gedistribueerde systemen waarbij alle soorten media betrokken zijn (tekst, video, enz.). In de kern is REST een stijl van het bouwen van systemen die flexibele communicatie en weergave van informatie op het web mogelijk maakt en tegelijkertijd structuur biedt die nodig is om eenvoudig componenten voor algemene doeleinden te bouwen.

In een REST API kan een bron vrijwel alles zijn, maar voorbeelden zijn een gebruiker, een lijst met tweets en de huidige resultaten van een zoekopdracht naar tweets. Elk van deze bronnen is adresseerbaar via een bron-ID , die in het geval van webgebaseerde REST API's meestal een URL is, zoals //api.twitter.com/1.1/users/show?screen_name=twitterdev. Wanneer een applicatie een resource aanvraagt ​​met behulp van de identifier, levert de API de huidige weergave van die resource aan de applicatie in een indeling die de applicatie kan gebruiken, zoals een JPEG-afbeelding, HTML-pagina of JSON.

Een van de grote onderscheidende factoren van REST is dat het gaat om het verzenden van gegevens naar de aanvragende applicatie. Hoewel dit een grote flexibiliteit biedt, waardoor de applicatie kan doen wat ze wil met de gegevens, gaat dit ten koste van de efficiëntie. Het verzenden van gegevens over het web voor verwerking is vrij traag in vergelijking met het verwerken van de gegevens op de locatie en vervolgens het verzenden van de resultaten.

Het probleem met de "efficiënte" benadering is natuurlijk dat systemen die de gegevens hosten, van tevoren moeten weten welke applicaties ermee willen doen. Dus om een ​​API te bouwen die algemeen bruikbaar en flexibel is, is REST de juiste keuze.

API-voorbeelden

Er zijn tal van openbare API's waarmee u kunt communiceren, veel van gigantische bedrijven uit de industrie. De mogelijkheid om programmatisch toegang te krijgen tot de code van een platformbedrijf via een API, maakt ze in wezen tot een platform. Enkele prominente API-voorbeelden zijn:

  • Google API's , waarmee u uw code kunt koppelen aan het hele scala aan Google-services, van Maps tot Translate. API's zijn zo belangrijk voor Google dat ze Apigee hebben overgenomen, een toonaangevend API-beheerplatform.
  • Facebook API's , waarmee u programmatisch toegang krijgt tot de sociale grafieken en marketingtools van Facebook. (Het bedrijf heeft beperkt tot welke gebruikersgegevens u toegang hebt via deze API's als gevolg van Cambridge Analytica en andere schandalen.)

Om echt een idee te krijgen van hoe API's werken, gaan we dieper ingaan op twee: de Java API, die Java-ontwikkelaars gebruiken om te communiceren met het Java-platform, en de Twitter API, een openbare API die je zou gebruiken om te communiceren met de sociale media. netwerkdienst.

De Java API

De Java API is een bibliotheek met softwarecomponenten die "out of the box" beschikbaar zijn voor iedereen die de Java Development Kit heeft geïnstalleerd. Deze componenten implementeren veelvoorkomende taken en verhogen over het algemeen de productiviteit omdat programmeurs niet elke keer opnieuw hoeven te beginnen. Een van de basiscomponenten die in software worden gebruikt, is een zogenaamde lijst, die, zoals je zou verwachten, een lijst met items bijhoudt. De Java API definieert wat u kunt doen met een lijst: items toevoegen, de lijst sorteren, bepalen of een item in de lijst staat, enz. Het specificeert ook hoe die acties moeten worden uitgevoerd. Om de lijst te sorteren, moet u specificeren hoe u de lijst wilt sorteren: alfabetisch, numeriek aflopend, helderste tot saaiste kleur, enz.

De Twitter API

De Twitter API is een webgebaseerde JSON API waarmee ontwikkelaars programmatisch kunnen communiceren met Twitter-gegevens. In tegenstelling tot de Java API, die is opgenomen in de Java Development Kit, is de Twitter API een webgebaseerde API. Het moet worden geopend door via internet verzoeken in te dienen bij services die Twitter host.

Met een webgebaseerde API zoals Twitter verstuurt uw applicatie een HTTP-verzoek, net zoals een webbrowser dat doet. Maar in plaats van dat het antwoord als een webpagina wordt afgeleverd, wordt het, voor menselijk begrip, geretourneerd in een indeling die applicaties gemakkelijk kunnen ontleden. Hiervoor bestaan ​​verschillende formaten en Twitter gebruikt een populair en gemakkelijk te gebruiken formaat genaamd JSON. (Als u niet bekend bent met JSON, wilt u er misschien een paar minuten over lezen.)

Een van de basiselementen van Twitter is een tweet. De Twitter API vertelt je wat je met tweets kunt doen: tweets zoeken, een tweet maken, een tweet favoriet maken. Het vertelt u ook hoe u deze acties moet uitvoeren. Om naar tweets te zoeken, moet u uw zoekcriteria specificeren: termen of hashtags om naar te zoeken, geolocatie, taal, enz.

API-ontwerp

API-ontwerp is het proces waarmee het "wat" en het "hoe" van een API wordt geformuleerd. Zoals met al het andere dat kan worden gemaakt, worden er verschillende niveaus van aandacht en zorg besteed aan het API-ontwerp, wat resulteert in verschillende niveaus van API-kwaliteit. Goed ontworpen API's gedragen zich consistent, houden rekening met hun context en houden rekening met de behoeften van hun gebruikers.

Consistent gedrag binnen een API heeft een grote invloed op de snelheid waarmee deze kan worden geleerd en op de kans dat programmeurs fouten maken bij het gebruik ervan. Over het algemeen moeten API's die vergelijkbare acties uitvoeren, zich op dezelfde manier gedragen, ongeacht hun technische verschillen. Laten we voor een voorbeeld van een inconsistente API eens kijken naar de twee manieren om een ​​item aan een lijst in Java toe te voegen:

Hoewel de twee methoden om items aan een lijst toe te voegen hetzelfde doen, zijn hun retourtypen (boolean en void) verschillend. Ontwikkelaars die deze API gebruiken, moeten nu bijhouden welke methode welk type retourneert, waardoor de API moeilijker te leren is en het gebruik ervan meer foutgevoelig is. Het betekent ook dat de code die deze methoden gebruikt, minder flexibel wordt, omdat deze moet veranderen als je de manier waarop je elementen toevoegt wilt wijzigen.

Rekening houden met de context is een andere vorm van consistentie, hoewel het te maken heeft met factoren buiten de API. Een geweldig, niet-softwarevoorbeeld hiervan is hoe de regel van de weg - rechts verkeer of links verkeer - auto-ontwerpen voor verschillende landen beïnvloedt. Auto-ontwerpers houden rekening met die omgevingsfactor bij het plaatsen van de bestuurdersstoel aan de rechter- of linkerkant van de auto.