Kickstart je API kennis met behulp van Memes!
Wist je dat API's je werk een stuk makkelijker en interessanter kunnen maken? In dit artikel lees je hier meer over en gaan we een Meme maken met behulp van een API.
APIs everywhere
Je hebt de afkorting vast al eens langs zien komen op de digitale snelweg. API's? Dat is toch iets met software ontwikkelen en programmeren enzo? Toch?
API is een afkorting voor Application Programming Interface. Een API zou je kunnen omschrijven als een speciale manier om te communiceren met een applicatie.
In de praktijk doe je dit vaak met behulp van een script of programmeer taal.
Het is een essentieel ingrediënt voor het maken van tools en combineert data of functionaliteit van verschillende bronnen.
Tegenwoordig heeft vrijwel elk IT software product of dienst een vorm van API ondersteuning.
Dit is geen toeval! Het geeft ons meer mogelijkheden voor creatieve oplossingen aan te bieden en onze productiviteit te verhogen.
Een paar voorbeelden van concrete API toepassingen in mijn dagelijks leven als IT Engineer:
- Klanten helpen besparen op maandelijkse kosten door het combineren van on-premise Active Directory last logon data met Office 365 licentie gebruik.
- Repeterende taken automatiseren zoals het aanmaken van nieuwe mailboxen in Exchange Online
- Automatiseren van standaard acties bij ticket registratie en afhandeling in TOPdesk.
API Bootcamp
API's onderscheiden zich met name op basis van het protocol waarmee ze werken. Dit bepaald namelijk allerlei eigenschappen zoals de data en commando's die geaccepteerd worden.
De scope van dit artikel zijn de zogenaamde REST API's. Dit protocol is namelijk het meest gangbaar en populair op dit moment. REST (een afkorting van REpresentational State Transfer) is een web API en werkt met populaire industrie standaarden zoals HTTP en JSON.
Om snel up to speed te komen heb ik kort de meest relevante termen beschreven waar je mee te maken hebt in REST API land:
- Endpoint is de naam van de URL waarmee je communiceert. Bijvoorbeeld https://api.twitter.com
- Path is het relatieve pad voor de resource die je wilt benaderen. Meer hierover later in dit artikel.
- JSON (JavaScript Object Notation) is de meest populaire standaard voor versturen en ontvangen van data via een REST API.
- Method geeft het type verzoek aan.
- GET: Dit verzoek is voor het ophalen van server data.
- POST: Creeert een nieuwe resource (data) op de server.
- PUT: Update een resource op de server.
- DELETE: Verwijdert een resource op een server.
- Headers worden gebruikt om informatie over een bepaald verzoek te geven. Een header wordt bijvoorbeeld vaak gebruikt om authenticatie data in op te slaan.
- Body is de data die je wil versturen of ontvangen. In de body kun je het daadwerkelijke verzoek aangeven wat verstuurd moet worden.
Authenticatie zonder tranen
Normaal gesproken moet je eerst authenticeren voordat je gebruik kan maken van een API. Eigenlijk precies hetzelfde principe als inloggen op Twitter voordat je een Tweet kunt plaatsen.
We kunnen op 2 manieren authenticeren:
- Met een gebruikersnaam en wachtwoord (ook wel bekend als basic authenticatie)
- Met een geheim token
Het inloggen met een token maakt het mogelijk om je bijvoorbeeld te authenticeren met social media accounts zoals van Twitter of Facebook. De meest bekende implementatie hiervan is oAuth.
Om het voorbeeld simpel te houden zal ik alleen gebruik maken van basic authenticatie. Hierbij wordt via de header een key-value pair verstuurd met daarin de credentials om verbinding te maken met de API.
De stappen hiervoor zijn:
- Neem de string "username:password" en codeer deze in Base64. De dubbele punt tussen gebruikersnaam en wachtwoord moet hierin opgenomen worden.
- Zet hier de string Basic (gevolgd door een spatie) voor.
- Maak een header door de nieuwe key-value aan te maken. De key wordt Authorization en de value Basic met daarachter de gecodeerde credential string. Voorbeeld:
Authorization: Basic abcdefgh123456789z
Wees voorzichtig met deze header. Het keypair is alleen gecodeerd met Base64. Dit is geen encryptie en is om te zetten naar plain text. Zorg daarom altijd dat de communicatie met de API over een HTTPS verbinding plaatsvindt!
Omdat de stappen voor het aanmaken van een basic authenticatie header vaak hetzelfde zijn kun je hiervoor een PowerShell functie maken.
In onderstaand voorbeeld zie je hoe zo'n functie eruit kan zien. Tevens kun je zien hoe je met behulp van deze authenticatie header verbinding kunt maken met de API van GitHub en een lijst van repositories kunt opvragen.
Waar blijven de memes!?
We hebben gezien hoe we informatie (repositories in dit geval), kunnen opvragen via een API. Maar echt leuk wordt het als we data kunnen schrijven. Ik zal gebruik maken van de API van imgflip om dit te laten zien.
Zoals ik eerder al aangegeven had heeft een REST API voor ieder type verzoek een ander pad (Path). De imgflip API maakt gebruik van 3 verschillende paden:
- https://api.imgflip.com (Root endpoint)
- https://api.imgflip.com/get_memes (Informatie over beschikbare memes opvragen)
- https://api.imgflip.com/get_memes/caption_image (Nieuwe informatie in de vorm van een grappige tekst toevoegen aan een meme en deze publiceren)
In het volgende voorbeeld kun je zien hoe we via het verbinden met het /caption_image path onze eigen teksten kunnen toevoegen.
Het is onderverdeeld in 4 delen, hieronder een korte beschrijving van ieder onderdeel.
1. Het aanmaken van de variabelen voor het API pad wat we willen aanspreken met het type verzoek.
2. Het aanmaken van een PowerShell object met alle parameters die nodig zijn om de meme van een tekst te voorzien.
template_id: Dit template ID wordt teruggekoppeld door een verzoek op het /get_memes pad. Deze zijn ook terug te vinden in de top 100.
username: Gebruikersnaam van een geldig imgflip account. Je kunt zelf hier een gratis account aanmaken.
password: Wachtwoord voor het imgflip account.
text0: Tekst die bovenaan de meme moet komen te staan.
text1: Tekst die onderaan de meme moet komen te staan.
Zoals je misschien wel is opgevallen verwacht de imgflip API het gebruikersnaam en wachtwoord in de body van het verzoek. In de praktijk zul je zien dat de vereisten om correct te authenticeren kunnen afwijken. Normaal gesproken zul je dit echter kunnen terugvinden in de documentatie van de API.
3. We hebben in stap 2 een PowerShell object gemaakt. Deze zetten we om naar JSON formaat zodat de API het verzoek begrijpt.
4. Het daadwerkelijk uitvoeren van het API verzoek.
Don't give it a REST
Ik hoop dat dit artikel je inzicht heeft gegeven in wat een API is en hoe deze werkt.
We hebben gezien dat API's het mogelijk maken om op een andere manier te werken met lezen en schrijven van data naar software en dit de deur kan openen voor allerlei creatieve oplossingen.
Dus don't give it a REST en start vandaag nog met het maken van je eerste API meme :-)
Troubleshooten met een tijdmachine!?
Wie heeft er niet eens een script vakkundig om zeep geholpen met het toevoegen van een "kleine verbetering"?
Na uren troubleshooten toch maar een oude versie uit de back-up restoren omdat je niet meer kunt terugvinden wat er ook alweer precies gewijzigd was?
Zou het niet geweldig zijn als we hiervoor een tijdmachine zouden kunnen gebruiken?
Versiebeheer.. Gaap!?
Goed nieuws want deze tijdmachines zijn er al jaren en noemen we in goed Nederlands een versie beheersysteem ;-)
In dit artikel wil ik je laten zien dat je geen softwareontwikkelaar hoeft te zijn om toch voordeel te hebben van een versie beheersysteem.
Versiebeheer is natuurlijk niets nieuws, de meeste mensen komen ermee in aanraking op het moment dat ze met documenten in Sharepoint of Google Docs gaan werken.
Voor software ontwikkelaars is versiebeheer echter een essentieel onderdeel van het werk en met het oog op trends zoals DevOps en IaaC denk ik dat het slechts een kwestie van tijd is voordat dit ook een onmisbaar stuk gereedschap gaat worden van de gemiddelde IT professional.
Steeds meer (IT beheer) software biedt de mogelijkheid voor integratie en automation en vaak is dit alleen mogelijk door het toepassen van regels code.
Versie beheersystemen kunnen helpen hier goed mee om te gaan.
De grootste voordelen zijn:
- Makkelijk teruggaan in de tijd naar een oudere (werkende) versie;
- Voorkomen dat er in oude versies wordt gewerkt;
- Inzicht in welke wijzigingen wanneer zijn doorgevoerd.
En last but zeker not least, versie beheer maakt een einde aan professionele bestandsnamen zoals Create-Aduser-v4_Fixed-MailBoxIssue_New_THIS-ONE-WORKS.ps1
Git
Wie versiebeheer zegt in software land, zegt Git. Git is een open source versie beheer systeem dat bedacht is door dè Linus Torvalds
In de meest simpele vorm kun je Git zien als een tabel waarin samen met een timestamp een overzicht van wijzigingen wordt weergegeven:
En wie is er tijdens de dagelijkse Google zoektochten naar een oplossing niet eens op Github terecht gekomen? Github is in 2016 door Microsoft aangekocht en op dit moment een van de meest populaire Cloud oplossing voor het samen werken aan software. Vrijwel ieder open source project maakt hier gebruik van.
Een van de grootste voordelen van Github is dat je op een gestructureerde manier een kopie kunt maken van een bestaand (werkend) project en de wijzigingen kunt integreren wanneer je er zeker van bent dat de wijzigingen geen problemen veroorzaken.
Praktijkvoorbeeld
Het is makkelijk om overrompeld te worden door Git. Zoals een echte IT-oplossing betaamd komen hier namelijk ook de nodige nieuwe gewichtige termen bij kijken zoals bijvoorbeeld forks en pull requests.
Daarom zal ik aan de hand van een concreet voorbeeld laten zien wat de toegevoegde waarde kan zijn:
Stel we hebben een opdracht gekregen voor het aanmaken van een subfolder genaamd OfficeAutoSave in de homefolder bij alle gebruikers accounts van een klant.
Na wat Googlen en testen hebben we een script gemaakt wat we hiervoor kunnen gebruiken:
Daarna krijgen we een nieuwe opdracht:
Omdat er problemen zijn met NTFS-rechten willen we graag een overzicht van de mapnaam inclusief NTFS eigenaar van iedere gebruiker.
Hiervoor passen we in het script regel 2 en 8 aan en slaan per ongeluk het bestand op onder dezelfde naam:
Met het overzicht kunnen we het probleem oplossen. We krijgen nu het verzoek om voor een andere map ook een aantal subfolders aan te maken. Echter willen we niet het wiel opnieuw uitvinden maar het script herstellen naar de oorspronkelijke staat.
Dit is het moment waarop we kunnen terugvallen op Git. In het screenshot hieronder zie je aan de linkerkant een overzicht van de zogenaamde commits. Dit zijn punten waarop Git een bestand heeft opgeslagen als een nieuwe revisie:
Aan de rechterkant kun je per revisie zien wat er precies is gewijzigd in de kleuren rood en groen. Je kunt je nu wel voorstellen hoeveel tijd het kan opleveren als je voortaan zo snel je wijzigingen kunt terugzoeken!
IT Toolbox
Persoonlijk denk ik dat dit een essentiële tool wordt voor iedere IT-professional, iets wat nu al het geval is voor elke software ontwikkelaar.
Hopelijk heb je door dit artikel iets meer inzicht gekregen in de kracht van een versiebeheer systeem zoals Git en is dit het startpunt voor het leren van een nieuwe vaardigheid!
Uitgelicht. Come Get IT spreker Maarten Eekels
Microsoft Teams is hot en mag daarom niet ontbreken op ons aanstaande evenement. Daarom kondig ik met veel plezier aan dat Maarten Eekels ons op 2 april zal vergezellen met maar een reden, om te praten over Teams!
Uitgelicht. Come Get IT spreker Erwin Derksen
Tijdens het aanstaande Come Get IT evenement staat de technologie van Microsoft centraal. Teams, WVD en… veiligheid zullen de primaire gespreksonderwerpen zijn. We hebben Erwin Derksen bereid gevonden om een presentatie te verzorgen rondom verschillende (aan Microsoft gerelateerde) veiligheid aspecten. Wie Erwin is en waar hij het o.a. over gaat hebben? Lees snel verder.
Het Come Get IT evenement 2 april aanstaande, wat je kunt verwachten
Een paar weken geleden plaatste ik (Bas) een kleine teaser m.b.t. ons aanstaande Come Get IT event. Het thema, zonder al te veel in detail te treden is Microsoft, ook dat deelde ik voorzichtig. Een dag later hadden we de eerste 25 inschrijvingen al binnen! Vrijwel allemaal extern. Dank jullie wel. In deze blog wil ik je alvast iets meer vertellen over wat we gaan doen en waar het evenement plaats gaat vinden.
5 (Cloud) alternatieven voor het aanbieden van je applicaties en desktops – deel 1
Nog niet zo lang geleden gaf ik een presentatie met de bovenstaande titel. Er zijn vele manieren om applicaties, data en desktops “aan de man” te brengen. In Nederland zijn met name de oplossingen van Citrix en VMware erg populair. Hoewel ik ze een warm hart toedraag kan het nooit kwaad om eens om je heen te kijken en je horizon te verbreden. Er zijn namelijk meerdere wegen die naar Rome leiden.
Wat is een gebruiker profiel, en tegen welke uitdagingen kun je aanlopen?
Iedere gebruiker heeft er een, een profiel. Of je nou op een fysieke machine werkt, laptop of desktop, een virtuele machine, multi-user of single-user het maakt niet uit. In het profiel van een gebruiker wordt persoonlijke informatie opgeslagen. Helaas kun je afhankelijk van de gekozen desktop of applicatie oplossing nog wel eens tegen bepaalde uitdagingen aan lopen. Vandaag bespreken we er een aantal.
Uitgelicht. Come Get IT spreker Jits Langedijk
Een van de sprekers tijdens het aanstaande Come Get IT evenement op 28 november aanstaande is Jits Langedijk. Jits is Senior Solution Architect bij NVIDIA en heeft een passie voor alles wat met zaken als deep (machine) Learning, Virtual Reality, vGPU’s & GRID technologieën te maken heeft. Een passie die hij binnenkort met ons zal gaan delen.
Uitgelicht. Come Get IT spreker Rob Tummers
Een van de sprekers tijdens het aanstaande Come Get IT evenement is Rob Tummers. Rob is Trainer en inspirator, oprichter en eigenaar van 2enable. Tijdens het Aanstaande Come Get IT event zal Rob een “mini” workshop voor ons gaan verzorgen.
Leve de Allrounders!
Het is tegenwoordig verleidelijk om als IT’er een specialisme te kiezen. Bedrijven en opleidingen duwen hun werknemers en studenten dan ook zachtjes in die richting. ‘Allrounder’ en ‘generalist’ zijn bijna vieze woorden geworden. Dat terwijl we juist deze mensen ook nodig hebben.
Ik ben jaren geleden bij een bedrijf begonnen waar direct gezegd werd: “Jullie waren generalisten, maar vanaf nu worden jullie IT-specialisten.” De bedoeling was dus dat we allemaal in een specialisme, een keurslijf geduwd werden, zonder dat we hier zelf om gevraagd hadden.
Dat is tegenwoordig een trend. In mijn werkzaamheden zie ik dat er steeds meer specialisten zijn die zich op specifieke diensten en onderdelen van IT richten. Er zijn IT’ers die zich bijvoorbeeld alleen maar met Exchange bezighouden, of alleen maar met Office 2019, afgezien van de ‘klassieke’ specialisaties zoals storage en networking.
Ik zie dit fenomeen ook in het dagelijks leven en dan met name bij jonge mensen.
Al op vroege leeftijd wordt er aangdrongen zich te specialiseren en zich voor te bereiden op een beroepskeuze terwijl veel en wellicht zelfs de meeste jongeren hier nog niet mee bezig zijn, laat staan klaar voor zijn.
Laat het duidelijk zijn, een specialist is ontzettend waardevol. Ik ben soms best wel jaloers op de mensen naast me die in detail zoveel meer weten en kunnen met het onderwerp waarmee ze bezig zijn maar ik merk ook dat specialisten met hun eigen valkuilen komen
Hoe steekt alles in elkaar?
Wat ik namelijk zie is dat er mensen zijn die zo gespecialiseerd zijn, dat ze het overzicht missen. Ze weten bij wijze van spreken niet wat er bij je buurman op kantoor gebeurt. Dat is niet erg als een probleem zich beperkt tot jouw specialisme maar dat is niet altijd het geval.
Een probleem kan ontstaan door een kapotte schakel in een serie van diensten en processen. Ben jij alleen maar bezig met Exchange en ligt de oorzaak van een probleem rondom Exchange ergens anders? Dan is de kans groot dat je het niet vindt. Je bestrijdt dan symptomen, maar niet het onderliggende probleem.
Het is voor bedrijven dus belangrijk dat er ook iemand aanwezig is die bredere kennis heeft en weet hoe dingen in elkaar haken, met name tijdens het uitvoeren van projecten of het oplossen van complexe issues. Dat kan best een specialist zijn. Iemand die net als ik ooit onderaan de ladder is begonnen, doet onderweg veel kennis op. Ook al gaat diegene zich – net als ik – later specialiseren, dan blijft die brede kennis behouden.
Er is balans nodig
Betekent dit dat de specialist moet verdwijnen? Zeker niet. Specialisten hebben ontzettend veel voordelen dankzij hun diepgaande kennis over één onderwerp. Zij zien problemen binnen hun eigen gebied die een ander nooit zou zien, omdat diegene niet weet waar je moet zoeken.
Een specialist zal het echter het onderliggende probleem van de symptomen die hij ziet niet snel vinden als dat probleem zich buiten zijn werkveld bevindt. Dat is waar je een allrounder voor nodig hebt, die de verbanden ziet en weet hoe alles in elkaar steekt. Kortom: je hebt een balans tussen die twee nodig.
‘Allrounder’ en ‘generalist’ zijn dus geen vieze woorden. Want wie zoek je als je een pro-troubleshooter nodig hebt? De allrounder!
