Hvad er en API? En forklaring for app-byggere

En API (application programming interface) er en defineret måde, ét stykke software kan bede et andet om data eller få det til at gøre noget. Din app sender en forespørgsel i et aftalt format — "giv mig morgendagens bookinger", "træk 20 € fra dette kort", "opsummér denne tekst" — og det andet system sender et struktureret svar tilbage. API'er er sådan, dele af en app taler sammen, og hvordan din app bruger eksterne tjenester som betalinger, e-mail, kort og AI.

Hvorfor API'er betyder noget, når du bygger med AI

Næsten alle nyttige apps er bygget af dele, der kommunikerer gennem API'er:

• Inde i din app kalder skærmene i browseren din egen backends API for at hente og gemme data.
• Uden for din app kalder din backend andre virksomheders API'er: Stripe til at tage betalinger, en e-mailudbyder til at sende kvitteringer, en AI-modeludbyder til at generere tekst.

Når du beder en AI-builder om at "tage betalinger" eller "tilføje et AI-resumé", skriver den i virkeligheden kode, der kalder en API. Med de grundlæggende begreber forstår du bedre, hvad AI'en har brug for fra dig (typisk en konto hos tjenesten og en API-nøgle), hvor tingene kan gå galt, og hvad de koster.

En hverdagsanalogi

Tænk på en restaurant. Du går ikke ind i køkkenet og laver mad. Du læser menuen, fortæller tjeneren, hvad du vil have, på en måde køkkenet forstår, og tjeneren bringer din mad tilbage — eller fortæller dig, at retten er udsolgt.

• Menuen er API-dokumentationen: en liste over, hvad du kan bede om, og hvordan.
• Tjeneren er API'en: den ene aftalte måde, forespørgsler kommer ind på, og svar kommer ud.
• Køkkenet er det andet system: du behøver ikke vide, hvordan det fungerer indvendigt.
• Din bestilling er forespørgslen; tallerkenen er svaret.

Køkkenet kan skifte ovne og personale uden at påvirke dig, så længe menuen forbliver den samme. Det er API'ens egentlige værdi: den lader to systemer arbejde sammen, uden at nogen af dem behøver at vide, hvordan den anden er bygget.

Sådan virker en web-API-forespørgsel

De fleste API'er, du støder på, er web-API'er, der virker over HTTP, den samme protokol din browser bruger. Hver forespørgsel har nogle få dele:

Og hvert svar har:

JSON (JavaScript Object Notation) er et simpelt tekstformat med navne og værdier i krølleparenteser. Det er standarden for, hvordan web-API'er udveksler data.

REST: den mest almindelige stil

REST er en udbredt konvention til at designe web-API'er. Hver type ting får sin egen URL, og standardmetoder siger, hvad du gør med den. Her er, hvordan en REST-API til en bookingapp kunne se ud:

PUT findes også og erstatter typisk en hel post, mens PATCH kun ændrer de felter, du sender.

Statuskoder, du oftest ser:

Når din app går i stykker, er statuskoden ofte det hurtigste fingerpeg. En 401 fra en betalingsudbyder betyder typisk en manglende eller forkert API-nøgle; en 429 betyder, at du kalder for ofte.

REST er ikke den eneste stil — GraphQL og RPC-lignende API'er findes også — men REST er det, de fleste tjenester og AI-byggede backends bruger.

Et eksempel: en bookingbekræftelse

Når en kunde booker en klipning i en frisørapp, kan flere API-kald ske på et sekund eller to:

1. Booking-siden i browseren sender POST /api/bookings med ydelse, tidspunkt og kundeoplysninger til din backend.
2. Din backend tjekker, at tidsrummet er ledigt, gemmer bookingen i databasen og returnerer 201 Created.
3. Din backend kalder en e-mailudbyders API med sin hemmelige nøgle: "send denne bekræftelse til lena@example.com."
4. Hvis der er en depositum, beder din backend betalingsudbyderens API om at oprette en checkout-session og sender kunden derhen.
5. Senere kalder betalingsudbyderen din app for at sige, at betalingen lykkedes. Det omvendte kald er en webhook.

De første to trin er din egen API mellem frontend og backend. Trin 3–5 er tredjeparts-API'er.

Almindelige begreber forklaret

Almindelige fejl og misforståelser

• At putte hemmelige nøgler i frontend'en. Alt i kode, der kører i browseren, kan ses af enhver, der besøger siden. Hemmelige nøgler skal blive på serveren, i miljøvariabler eller hemmeligheder.
• At indsætte nøgler i chatten. Chathistorikken kan gemmes. Brug i stedet din builders hemmelighedsfunktion, og roter enhver nøgle, du har afsløret.
• At antage, at en API er gratis. Mange API'er tager betaling pr. forespørgsel eller pr. forbrugsenhed — AI-model-API'er tager betaling pr. token. Tjek priserne, og sæt forbrugsgrænser. Se sådan bruger du LLM-API'er.
• At ikke håndtere fejl. Eksterne tjenester går ned, får timeouts og rammer grænser. Bed om fornuftige fejlmeddelelser og nye forsøg.
• At stole på browseren. Din egen API skal selv tjekke tilladelser. At skjule en knap stopper ikke nogen i at kalde endpointet direkte.
• At bruge live-nøgler under test. Brug testmode-nøgler, indtil du er klar til lancering.

Hvad du skal bede din AI-builder om

• "Hvilke eksterne API'er bruger denne app, og hvad koster hver af dem?"
• "Kald betalings-API'en kun fra serveren. Læs nøglen fra en miljøvariabel."
• "List hvert endpoint i vores API, hvad det gør, og hvem der må kalde det."
• "Tjek på serveren, at den indloggede bruger ejer bookingen, før den opdateres eller slettes."
• "Hvis e-mail-API'en fejler, så gem bookingen alligevel og log fejlen."
• "Brug udbyderens testmode indtil videre."

API'er i Mythex

Mythex kan bygge din egen API — som en del af en webapp eller som en separat backend i Node, Python (FastAPI), C# eller Java, der kører ved siden af din frontend — og skrive koden, der kalder eksterne tjenester. Du tilføjer deres nøgler som projekthemmeligheder i stedet for i chatten, og de er tilgængelige for din app i preview og, når den er publiceret. Dokumentationen har opskrifterne integrer enhver API og byg en REST-API-backend.

Spørgsmål