Vad är ett API?

Ett API (Application Programming Interface) är en uppsättning regler som gör att en mjukvara kan kommunicera med en annan. Tänk på det som en meny: din app kan "beställa" data eller åtgärder, och API:et talar om för köket (en tjänst) exakt vad som ska tillagas och hur det ska serveras.

API:er standardiserar hur förfrågningar görs och hur svar returneras, så att olika system kan samverka på ett tillförlitligt sätt även om de har utvecklats av olika team, företag eller i olika programmeringsspråk.

På en grundläggande nivå definierar ett API slutpunkter (adresser du kan anropa), de metoder du kan använda (som GET för att hämta data eller POST för att skicka data), formatet på det du skickar (ofta JSON) och vad du kan förvänta dig tillbaka (data plus en statuskod som 200 för ”OK” eller 404 för ”Hittades inte”). Denna förutsägbarhet är hela poängen.

• API: Kontraktet vad du kan begära och hur du får svar.
• SDK (Software Development Kit): Ett verktygspaket som ofta innehåller ett API med färdig kod, exempel och verktyg för att underlätta användningen av API:et.
• UI (användargränssnitt): Det som människor klickar och trycker på. API:er är för programvara till programvara; UI:er är för människor.

Om du vill vara exakt kan du använda ett API utan ett SDK, men att använda ett SDK kan spara tid och minska risken för misstag.

Ja, flera stilar, var och en med sina för- och nackdelar:

• REST: Den vanligaste webbstilen idag. Resursbaserad, använder HTTP-metoder (GET/POST/PUT/DELETE), vanligtvis JSON.
• GraphQL: Kunderna anger exakt vilka fält de behöver i en enda förfrågan – perfekt för att minska över- eller underhämtning.
• SOAP: Äldre XML-baserat protokoll med strikta avtal som fortfarande används i vissa företag.
• gRPC: Högpresterande binärt protokoll som är populärt för mikrotjänster.
• Webhooks: Inte en begäran som du gör, utan ett återuppringningsmeddelande som leverantören skickar till dig när något händer (till exempel en leveransbekräftelse).

Vanligtvis, ja. Istället för att bygga allt själv kan du med hjälp av API:er koppla in betalningar, kartor, e-post, sökfunktioner, analyser, AI och mycket mer. Det sparar tid för teknikerna, förbättrar tillförlitligheten (leverantören håller sin tjänst uppdaterad) och låter ditt team fokusera på det som gör din produkt unik.

Nackdelarna: du ärver hastighetsbegränsningar, prissättning och drifttidsberoenden från din leverantör. Om din produkt inte kan fungera utan det API:et, planera för redundans.

Ofta. Många API:er kräver autentisering så att leverantören vet vem du är och kan tillämpa behörigheter och hastighetsbegränsningar. Vanliga metoder är:

• API-nycklar: Enkla tokens som du skickar med varje förfrågan.
• OAuth: En säkrare, delegerad metod som är utmärkt när du behöver åtkomst på en användares vägnar.
• Signerade förfrågningar/JWT: Kryptografiskt signerade tokens som löper ut och kan innehålla påståenden (vem du är, vad du har tillåtelse att göra).

Håll nycklar och tokens borta från offentliga repositorier och klientkod när det är möjligt.

Inte direkt. En webbläsare, curl eller vilken HTTP-klient som helst fungerar för många API:er. Utvecklare använder ofta verktyg som Postman eller inbyggda språkbibliotek för att göra förfrågningar, granska svar och spara exempel. För produktionsappar använder du ditt språks HTTP-bibliotek eller leverantörens SDK.

I stort sett allt som är modernt: mobilappar som hämtar profiler, "Logga in med Google/Apple", onlinebutiker som hanterar betalningar, synkronisering av smarta hem-enheter, instrumentpaneler som hämtar analyser, till och med din väderwidget. Om programvara utbyter data finns det troligen ett API under huven.

• Slutpunkt: Den URL du anropar (t.ex. /users/123).
• Begäran/svar: Vad du skickar jämfört med vad du får tillbaka.
• Nyttolast/kropp: Data i en begäran eller ett svar.
• Statuskod: Numeriskt resultat (200 OK, 201 Skapad, 401 Obehörig, 429 För många förfrågningar, 500 Serverfel).
• Hastighetsbegränsning: Hur många samtal du kan ringa under en viss tidsperiod.
• Versionering: Hålla gamla och nya API-funktioner åtskilda (t.ex. /v1/ vs. /v2/).
• Idempotent: Att göra samma begäran flera gånger ger samma resultat (t.ex. GET).