API står for applikationsprogrammeringsgrænseflade, et koncept, der gælder overalt fra kommandolinjeværktøjer til virksomhedens Java-kode til Ruby on Rails webapps. En API er en måde at interagere programmatisk med en separat softwarekomponent eller ressource.
Medmindre du skriver hver eneste linje kode fra bunden, interagerer du med eksterne softwarekomponenter, hver med sin egen API. Selvom du skriver noget helt fra bunden, vil et veldesignet softwareapplikation have interne API'er, der hjælper med at organisere kode og gøre komponenter mere genanvendelige. Og der er adskillige offentlige API'er, der giver dig mulighed for at udnytte funktionalitet udviklet andetsteds på nettet.
Hvad er en API?
En API er defineret som en specifikation af mulige interaktioner med en softwarekomponent. Hvad betyder det præcist? Forestil dig, at en bil var en softwarekomponent. Dens API vil indeholde oplysninger om hvad det kan - accelerere, bremse, tænde radioen osv. Det vil også indeholde oplysninger om hvordan du kunne få det til at gøre disse ting. For eksempel for at accelerere sætter du foden på gaspedalen og skubber.
API behøver ikke at forklare, hvad der sker inde i motoren, når du sætter din fod på speederen. Derfor, hvis du lærte at køre en bil med en forbrændingsmotor, kan du sætte dig bag rattet i en elbil uden at skulle lære et helt nyt sæt færdigheder. Det hvad og hvordan information samles i API'et definition, som er abstrakt og adskilt fra selve bilen.
En ting at huske på er, at navnet på nogle API'er ofte bruges til at henvise til både specifikationen af interaktionerne og til den aktuelle softwarekomponent, du interagerer med. Udtrykket "Twitter API" henviser for eksempel ikke kun til regelsættet for programmatisk interaktion med Twitter, men forstås generelt at betyde det, du interagerer med, som i "Vi laver analyse på tweets, vi fik fra Twitter API. ”
API som abstraktionslag
Når det kommer til software, er API'er bogstaveligt talt overalt. API'er går hånd i hånd med et af de mest grundlæggende begreber inden for datalogi: abstraktion. Abstraktion er bare en måde at organisere et systems kompleksitet på, så komplicerede handlinger kan håndteres på en enkel måde. Tænk på denne abstraktion som de Amazon Dash-knapper, de batteridrevne trykknapkort, du kan bruge til at bestille hæfteklammer fra Amazon. Sådan ser de ud:
Du bestiller en Dash-knap fra Amazon og bruger en app på din smartphone til at knytte den til dit Wi-Fi-netværk, din Amazon-konto og et produkt, fx dit yndlingsmærke papirhåndklæder. Så når du vil bestille flere papirhåndklæder, skal du bare trykke på knappen. Dash-knappen opretter forbindelse til internettet og sender en besked for at placere en ordre på din konto. Et par dage senere ankommer papirhåndklæder lige uden for døren.
Ligesom en API er Dash-knappen en salig simpel grænseflade, der skjuler al slags kompleksitet bag kulisserne. ID'et på det produkt, du bestilte, skal hentes fra en eller anden database. Din leveringsadresse skal trækkes fra din konto. Det nærmeste opfyldelsescenter, der har dine papirhåndklæder, skal bestemmes og derefter underrettes om at fjerne en vare fra den tilgængelige lager og pakke den sammen. Endelig skal pakken dirigeres gennem en kombination af fly, lastbiler og varevogne sammen med andre pakker på en måde, der sikrer, at alle pakkerne når deres destinationer effektivt.
Forestil dig nu, at du var nødt til at koordinere alle disse ting som kunde. Du vil aldrig bestille papirhåndklæder, fordi det er for kompliceret og tidskrævende, og du har bedre ting at gøre. Heldigvis er hele prøvelsen abstraheret væk fra dig. Der er en lang sammenkoblet kæde af computersystemer og menneskelige processer, der får disse papirhåndklæder til at dukke op lige uden for døren, men alt hvad du skal tænke på er at trykke på en knap.
Sådan er API'er for programmører. De tager en overvældende mængde af kompleksitet og definerer et relativt simpelt sæt interaktioner, som du kan bruge i stedet for at gøre det hele selv. I ethvert softwareprojekt bruger du sandsynligvis ti, hvis ikke hundreder af API'er direkte, og hver af disse API'er er afhængige af andre API'er og så videre.
Offentlige API'er og API-integration
API'er er et langvarigt koncept inden for computerprogrammering, og de har været en del af udvikleres værktøjssæt i årevis. Traditionelt blev API'er brugt til at forbinde kodekomponenter, der kører på den samme maskine. Med stigningen af allestedsnærværende netværk mere og mere offentlige API'er, undertiden kaldes åbne API'er, er blevet tilgængelige. Offentlige API'er vender udad og er tilgængelige over internettet, så du kan skrive kode, der interagerer med andre leverandørers kode online; denne proces er kendt som API-integration.
Denne slags kodemashups giver brugerne mulighed for at blande og matche funktionalitet fra forskellige leverandører på deres egne systemer. For eksempel, hvis du bruger marketingautomatiseringssoftwaren Marketo, kan du synkronisere dine data der med Salesforce CRM-funktionalitet.
"Åben" eller "offentlig" skal ikke fortolkes som "gratis" i denne sammenhæng. Du skal stadig være Marketo- og Salesforce-kunde for at dette kan fungere. Men tilgængeligheden af disse API'er gør integration til en meget enklere proces, end den ellers ville være. ( har en god liste over offentlige API'er, du bør vide om.)
Webtjenester og API'er
Du husker måske udtrykket web-tjenester fra begyndelsen af 00'erne og synes, at ideen om en åben API lyder temmelig ens. Faktisk er en webtjeneste en bestemt form for åben API, der opfylder et ret stift sæt specifikationer, herunder at de er specificeret i Web Services Description Language (WSDL), en XML-variant.
Webtjenester var beregnet til at blive brugt som en del af en serviceorienteret arkitektur (SOA). Som den nordiske API-blog forklarer, gav det webtjenester noget af et dårligt navn, da SOA'er aldrig helt levede op til deres potentiale. Fremskridt med de teknikker, der bruges til service-til-service-kommunikation - især lettere, mere fleksibel REST - har også efterladt webtjenester noget bagud i verdenen af offentlige API'er.
REST API'er
Webtjenester blev oprindeligt designet til at kommunikere ved hjælp af SOAP (Simple Object Access Protocol), en beskedprotokol, der sender XML-dokumenter via HTTP. I dag bruger de fleste webbaserede API'er imidlertid REST - Representational State Transfer - som en arkitektonisk stil.
REST blev formelt introduceret af Roy Fielding i sin doktorafhandling i 2000. Det er et sæt arkitektoniske komponenter, designprincipper og interaktioner, der bruges til at opbygge distribuerede systemer, der involverer medier af enhver art (tekst, video osv.). I sin kerne er REST en byggestil, der giver mulighed for fleksibel kommunikation og visning af information på nettet, samtidig med at den giver struktur, der er nødvendig for nemt at opbygge komponenter til generelle formål.
I en REST API er en ressource kunne være stort set alt, men eksempler inkluderer en bruger, en liste over tweets og de aktuelle resultater af en søgning efter tweets. Hver af disse ressourcer kan adresseres på en ressourceidentifikator, som i tilfælde af webbaserede REST API'er normalt er en URL, såsom //api.twitter.com/1.1/users/show?screen_name=twitterdev. Når en applikation anmoder om en ressource ved hjælp af identifikatoren, leverer API den aktuelle repræsentation af denne ressource til applikationen i et format, som applikationen kan forbruge, f.eks. et JPEG-billede, HTML-side eller JSON.
En af de store differentiatorer af REST er, at det indebærer at sende data til den anmodende applikation. Selvom dette giver stor fleksibilitet, hvilket gør det muligt for applikationen at gøre hvad det vil med dataene, kommer det på bekostning af effektiviteten. Afsendelse af data over internettet til behandling er ret langsom i forhold til at udføre behandlingen, hvor dataene ligger, og derefter sende resultaterne.
Naturligvis er problemet med den "effektive" tilgang, at systemer, der hoster dataene, skal vide, hvad applikationer vil gøre med det på forhånd. For at opbygge en API, der har brugbarhed og fleksibilitet til generelle formål, er REST således vejen at gå.
API eksempler
Der er masser af offentlige API'er derude, som du kan interagere med, mange fra branchejern. Evnen til at få adgang til nogle platformfirmas kode programmatisk via en API er det, der gør dem til en platform, i det væsentlige. Nogle fremtrædende API-eksempler inkluderer:
- Google API'er, som giver dig mulighed for at forbinde din kode til hele spektret af Google-tjenester, fra Maps til Translate. API'er er så vigtige for Google, at de erhvervede Apigee, en førende API-styringsplatform.
- Facebook API'er, som giver dig programmatisk adgang til Facebooks sociale graf og marketingværktøjer. (Virksomheden har begrænset, hvilke brugerdata du har adgang til via disse API'er i nedfaldet fra Cambridge Analytica og andre skandaler.)
For virkelig at få en fornemmelse af, hvordan API'er fungerer, lad os lave et dybt dyk i to: Java API, som Java-udviklere bruger til at interagere med Java-platformen, og Twitter API, en offentlig API, som du vil bruge til at interagere med det sociale netværkstjeneste.
Java API
Java API er et bibliotek med softwarekomponenter, der er tilgængelige "ud af æsken" for alle, der har installeret Java Development Kit. Disse komponenter implementerer fælles opgaver og øger generelt produktiviteten, fordi programmører ikke behøver at starte fra bunden hver gang. En af de grundlæggende komponenter, der bruges i software, er noget, der kaldes en liste, som, som du måske forventer, holder styr på en liste over emner. Java API definerer hvad du kan gøre med en liste: tilføj emner, sorter listen, bestem om et element er på listen osv. Det specificeres også hvordan at udføre disse handlinger. For at sortere listen skal du angive, hvordan du vil have listen sorteret: alfabetisk, numerisk faldende, lyseste til kedeligste farve osv.
Twitter API
Twitter API er en webbaseret JSON API, der giver udviklere mulighed for programmatisk at interagere med Twitter-data. I modsætning til Java API, som er inkluderet i Java Development Kit, er Twitter API en webbaseret API. Det skal tilgås ved at fremsætte anmodninger over internettet til tjenester, som Twitter er vært for.
Med en webbaseret API som f.eks. Twitter sender din applikation en HTTP-anmodning, ligesom en webbrowser gør. Men i stedet for at svaret leveres som en webside, for menneskelig forståelse, returneres det i et format, som applikationer let kan analysere. Der findes forskellige formater til dette formål, og Twitter bruger et populært og brugervenligt format kaldet JSON. (Hvis du ikke er fortrolig med JSON, kan du bruge et par minutter på at læse om det her.)
Et af de grundlæggende elementer i Twitter er en tweet. Twitter API fortæller dig hvad du kan gøre med tweets: søg efter tweets, opret en tweet, favorit en tweet. Det fortæller dig også hvordan at udføre disse handlinger. For at søge efter tweets skal du angive dine søgekriterier: termer eller hashtags, du skal kigge efter, geografisk placering, sprog osv.
API-design
API-design er den proces, hvor "hvad" og "hvordan" til en API formuleres. Som med alt andet, der kan oprettes, lægges forskellige niveauer af tanke og omhu i API-design, hvilket resulterer i varierende niveauer af API-kvalitet. Veltilrettelagte API'er har ensartet adfærd, tager deres kontekst i betragtning og holder brugernes behov i tankerne.
Konsistent adfærd inden for en API påvirker i høj grad den hastighed, hvormed den kan læres, og sandsynligheden for, at programmører laver fejl, når de bruger den. Generelt skal API'er, der udfører lignende handlinger, opføre sig ens, uanset deres tekniske forskelle. For et eksempel på en inkonsekvent API, lad os se på de to måder at føje et element til en liste i Java:
Selvom de to metoder til at tilføje varer til en liste gør det samme, er deres returtyper (boolsk og ugyldig) forskellige. Udviklere, der bruger denne API, skal nu holde styr på, hvilken metode der returnerer hvilken type, hvilket gør API sværere at lære og dens anvendelse mere udsat for fejl. Det betyder også, at koden, der bruger disse metoder, bliver mindre fleksibel, fordi den skal ændres, hvis du vil skifte den måde, du tilføjer elementer på.
At tage kontekst i betragtning er en anden form for konsistens, selvom det har at gøre med faktorer uden for API. Et godt, ikke-softwareeksempel på dette er, hvordan vejreglen - højre- eller venstrekørsel - påvirker bildesign i forskellige lande. Bildesignere tager denne miljøfaktor i betragtning, når de finder førersædet på højre eller venstre side af bilen.
