Hva er et API? En enkel guide for app-byggere

Et API (application programming interface) er en definert måte for ett stykke programvare å be et annet om data, eller å få det til å gjøre noe. Appen din sender en forespørsel i et avtalt format — «gi meg morgendagens bookinger», «belast dette kortet med 20 €», «oppsummer denne teksten» — og det andre systemet sender tilbake et strukturert svar. API-er er slik delene av en app snakker sammen, og slik appen din bruker eksterne tjenester som betalinger, e-post, kart og AI.

Hvorfor API-er betyr noe når du bygger med AI

Nesten alle nyttige apper består av deler som kommuniserer gjennom API-er:

• Inne i appen din kaller skjermbildene i nettleseren backendens eget API for å laste og lagre data.
• Utenfor appen din kaller backenden din andre selskapers API-er: Stripe for å ta betalinger, en e-postleverandør for å sende kvitteringer, en leverandør av AI-modeller for å generere tekst.

Når du ber en AI-bygger om å «ta betalinger» eller «legge til et AI-sammendrag», er det det den egentlig gjør: skriver kode som kaller et API. Å kjenne det grunnleggende hjelper deg å forstå hva AI-en trenger fra deg (vanligvis en konto hos den tjenesten og en API-nøkkel), hvor ting kan gå galt, og hva de vil koste.

En hverdagslig sammenligning

Tenk på en restaurant. Du går ikke inn på kjøkkenet og lager mat. Du leser menyen, forteller servitøren hva du vil ha på en måte kjøkkenet forstår, og servitøren bringer maten tilbake — eller forteller deg at retten er utsolgt.

• Menyen er API-dokumentasjonen: en liste over hva du kan be om, og hvordan.
• Servitøren er API-et: den ene avtalte måten forespørsler kommer inn og svar kommer ut på.
• Kjøkkenet er det andre systemet: du trenger ikke vite hvordan det fungerer inni.
• Bestillingen din er forespørselen; tallerkenen er svaret.

Kjøkkenet kan bytte ovner og personale uten å påvirke deg, så lenge menyen er den samme. Det er den egentlige verdien av et API: det lar to systemer fungere sammen uten at noen av dem trenger å vite hvordan den andre er bygget.

Slik fungerer en web-API-forespørsel

De fleste API-ene du møter er web-API-er som fungerer over HTTP, den samme protokollen nettleseren din bruker. Hver forespørsel har noen få deler:

Og hvert svar har:

JSON (JavaScript Object Notation) er et enkelt tekstformat med navn og verdier i krøllparenteser. Det er standardmåten web-API-er utveksler data på.

REST: den vanligste stilen

REST er en mye brukt konvensjon for å designe web-API-er. Hver type ting får sin egen URL, og standardmetoder sier hva du gjør med den. Her er hvordan et REST-API for en bookingapp kan se ut:

PUT finnes også og erstatter etter konvensjon en hel post, mens PATCH bare endrer feltene du sender.

Statuskodene du oftest vil se:

Når appen din slutter å fungere, er statuskoden ofte det raskeste spornet. En 401 fra en betalingsleverandør betyr vanligvis at en API-nøkkel mangler eller er feil; en 429 betyr at du kaller for ofte.

REST er ikke den eneste stilen — GraphQL og RPC-lignende API-er finnes også — men REST er det de fleste tjenester og AI-bygde backender bruker.

Et eksempel: en bookingbekreftelse

Når en kunde booker en klipp i en frisørapp, kan flere API-kall skje i løpet av et sekund eller to:

1. Bookingsiden i nettleseren sender POST /api/bookings med tjenesten, tidspunktet og kundens detaljer til backenden din.
2. Backenden din sjekker at tidsrommet er ledig, lagrer bookingen i databasen, og returnerer 201 Created.
3. Backenden din kaller en e-postleverandørs API med sin hemmelige nøkkel: «send denne bekreftelsen til lena@example.com».
4. Hvis det er et depositum, ber backenden din betalingsleverandørens API om å opprette en utsjekkingsøkt, og sender kunden dit.
5. Senere kaller betalingsleverandøren din app for å si at betalingen gikk gjennom. Dette omvendte kallet er en webhook.

De to første stegene er ditt eget API mellom frontend og backend. Stegene 3–5 er tredjeparts-API-er.

Vanlige begreper forklart

Vanlige feil og misforståelser

• Å legge hemmelige nøkler i frontend. Alt i kode som kjører i nettleseren kan ses av hvem som helst som besøker siden. Hemmelige nøkler må forbli på serveren, i miljøvariabler eller hemmeligheter.
• Å lime nøkler inn i chatten. Chatthistorikken kan bli lagret. Bruk heller byggerens funksjon for hemmeligheter, og roter (bytt ut) alle nøkler du har eksponert.
• Å anta at et API er gratis. Mange API-er tar betalt per forespørsel eller per bruksenhet — AI-modell-API-er tar betalt per token. Sjekk prisene og sett forbruksgrenser. Se hvordan du bruker LLM-API-er.
• Å ikke håndtere feil. Eksterne tjenester går ned, får tidsavbrudd og treffer grenser. Be om fornuftige feilmeldinger og nye forsøk.
• Å stole på nettleseren. Ditt eget API må selv sjekke tillatelser. Å skjule en knapp stopper ikke noen fra å kalle endepunktet direkte.
• Å bruke live-nøkler under testing. Bruk testmodus-nøkler til du er klar til å lansere.

Hva du skal be AI-byggeren om

• «Hvilke eksterne API-er bruker denne appen, og hva koster hver av dem?»
• «Kall betalings-API-et kun fra serveren. Les nøkkelen fra en miljøvariabel.»
• «List hvert endepunkt i API-et vårt, hva det gjør, og hvem som har lov til å kalle det.»
• «Sjekk på serveren at innlogget bruker eier bookingen før den oppdateres eller slettes.»
• «Hvis e-post-API-et feiler, lagre bookingen likevel og logg feilen.»
• «Bruk leverandørens testmodus foreløpig.»

API-er i Mythex

Mythex kan bygge ditt eget API — som en del av en nettapp, eller som en egen backend i Node, Python (FastAPI), C# eller Java som kjører ved siden av frontend-en din — og skrive koden som kaller eksterne tjenester. Du legger inn nøklene deres som prosjekthemmeligheter i stedet for i chatten, og de er tilgjengelige for appen din i forhåndsvisningen og etter publisering. Dokumentasjonen har oppskrifter for integrering av et hvilket som helst API og bygging av en REST-API-backend.

Spørsmål