Denne klumme er et debatindlæg og er alene udtryk for forfatterens synspunkter
Vi er i en branche med rigtig mange forkortelser og begreber. Der sker ofte det, at en eller anden teknologi bliver nævnt, og så lader alle som om, at de ved, hvad der tales om.
Det seneste, jeg faldt over, var et såkaldt "restful API", som alle – undtagen mig – tilsyneladende forstod til fulde.
Endnu engang vil jeg godt meddele min delvise uvidenhed. Men heldigvis forholder det sig sådan i en moderne oplysningstid, at det ligger alle frit for at undersøge et emne og dele ud af sin nyerhvervede viden. Det er vel også det, der kaldes for ”knowledge sharing”.
Basalt set, så er hele ”knowledge sharing”-princippet nok den vigtigste faktor for vores civilisations udvikling. Så første skridt er ikke ”jeg ved, hvad jeg ved”, men snarere ”jeg ved, hvad jeg ikke ved”.
Nuvel – tilbage på sporet – denne klumme handler om protokoller og API’er. Tillad mig at ”tech-splaine” lidt om it-verdenens ubesungne og usynlige helte:
Det første, man skal vide, er, hvad en protokol er. Og for at få det helt ned på jorden, så er en protokol blot en betegnelse for det sprog, som både afsender og modtager bliver enige om at tale. Man kan sammenligne det med det talte sprog.
Jeg havde engang en engelsk chef, der hed David. Og jeg kan allerede nu afsløre, at hans danske sprogkundskaber var tæt på ikke-eksisterende.
Det på trods af, at rigtig mange engelske ord og stednavne faktisk stammer fra dansk. Det kan vi takke vikingerne for. Og derudover, så har dansk og engelsk kultur rigtig mange fællestræk. Men det er en helt anden historie.
Ikke desto mindre, så kunne David kun tale engelsk. Det kunne jeg også. Eller det troede jeg, at jeg kunne.
I Danmark har vi nemlig en opfattelse af, at vi er gode til engelsk. Men for mit eget vedkommende, så kan jeg afkræfte dette. Men efter 3½ år med adskillige daglige samtaler på engelsk, så begyndte det at hjælpe på det. Det er vist også det, man kalder en ’ubevidst inkompetence’.
Uanset hvad, så fik vi defineret en fælles protokol i det engelske sprog, og dermed kunne vi tale sammen.
På samme måde har vi nøjagtig det samme i it-verdenen.
Stort set alle har hørt om IP-protokollen (Internet Protocol), som er hele grundlaget for kommunikation på internettet. Og alle browsere benytter HTTP-protokollen (HyperText Transfer Protocol) til visning af hjemmesider. Og dét uanset om du benytter Edge, Chrome, FireFox, Safari og så videre. Og dermed har man forenklet og ensartet kommunikationen.
Med hensyn til et API (Application Programming Interface), så er funktionen af dette også at forenkle tingene. Nogle kalder det også for et abstraktionsIag, men jeg kalder det blot at skjule unødvendig kompleksitet.
Tillad mig at give et par eksempler:
Et klassisk eksempel er at betragte et API som en tjener på en restaurant. Du afgiver en bestilling til tjeneren. Tjeneren tager bestillingen med ud i køkkenet. Køkkenet tilbereder din mad. Og når din mad er færdig, så bringer tjeneren maden til dit bord. Men du slipper for at vide, hvordan din mad rent faktisk er tilberedt.
I 90’erne var client/server-begrebet meget anvendt. Og det er nøjagtig den samme metode, som et API anvender. Client/server-princippet lever i bedste velgående.
På samme måde kan man også sammenligne det med at køre bil.
De fleste har et kørekort og kan dermed føre en bil via bilens instrumenter. Men alt hvad der foregår fra instrumentbrættet og ud til motorrummet, hjulene og så videre er hverken relevant eller nødvendigt at vide.
Instrumentbrættet fortæller dig således ikke i detaljer, hvordan informationerne er frembragt. Instrumentbrættet leverer udelukkende relevante og letforståelige informationer til dig som fører køretøjet.
Overfører man dette til computerteknologi er et API en softwaregrænseflade, der tillader et stykke software at kommunikere med andet stykke software. API’er findes alle mulige steder, f.eks. i din computer, din smartphone, et operativsystem, dine applikationer og så videre.
Sagt på en anden måde, så er et API en slags kontrakt mellem to stykker software. En kontrakt, der tillader en struktureret måde at udveksle data og informationer på.
Tillad mig også her at give et par eksempler:
I gamle dage havde vi store centrale computere kaldet mainframes. En mainframe består af forholdsvis kompliceret hardware og software. For ikke at alle skulle lære alt om en mainframe for at kunne integrere med denne, blev der udviklet API’er for at lette integrationen. Et eksempel er IBM’s z/OS Connect Enterprise Edition.
Og i nyere tid er nogen måske stødt på begrebet 'Restful API'.
Et Restful API (Representation State Transfer) er en nyere definition af begrebet et API. Hvis du ser på alle moderne web-baserede appliktioner, så er kravet til disses integrationsmuligheder enorme. Og derfor er et Restful API et API på steroider. Og så er det lavet til web’en.
Et Rest API og et Restful API er i øvrigt det samme. Restful API’er er simple, standardiserede og anvendt i hele industrien. Og så kan Restful API’er skaleres, og de er ekstremt hurtige.
Hvis du eksempelvis har undret dig over, hvorfor rejseportaler er så hurtige til at svare, eller hvorfor streaming-tjenester er så hurtige til at finde en sang eller en video, ja, så skyldes det Restful API’er.
Restful API’er er i den grad allestedsnærværende, og du anvender dem hele tiden.
Så API’er er over det hele og er med til at gøre livet meget lettere for både brugere og udviklere. Faktisk taler man om en såkaldt ”API Economy”, da stort set alle moderne it-tjenester og produkter er baseret på anvendelsen af API’er. Du ser det blot ikke.
Sværere er det såmænd ikke.
Klummer er læsernes platform på Computerworld til at fortælle de bedste historier, og samtidig er det vores meget populære og meget læste forum for videndeling.
Har du en god historie eller har du specialviden, som du synes trænger til at blive delt?
Læs vores klumme-guidelines og send os din tekst, så kontakter vi dig - måske bliver du en del af vores hurtigt voksende korps af klummeskribenter.
