API

API (Application Programming Interface) eli rajapinta on sovitut tavat, joilla ohjelmat pyytävät toisiltaan tietoa tai toimintoja. Web-kehityksessä API on tyypillisesti HTTP-osoite, johon lähetät pyynnön ja josta saat vastauksen JSON-muodossa. Kuvittele ravintolan tarjoilija: tilaat ruoan tarjoilijalta, et kulje itse keittiöön, ja tarjoilija tuo vastauksen takaisin.

Vibekoodaajan sovelluksessa API:ita on useassa kohdassa. Frontend hakee dataa oman backendin API:sta, ja backend puhuu kolmannen osapuolen API:en kanssa, kuten Stripe maksuille, Supabase tietokannalle tai tekoälymallin API tekstin tuottamiselle. Claude Code, Cursor ja Lovable osaavat rakentaa molemmat suunnat. Next.js:ssä oman API:n luominen on helppoa: lisäät route.ts-tiedoston app/api/-kansioon, ja tiedoston polku määrää osoitteen. API:n käyttöönotto alkaa lähes aina samasta: luet dokumentaation, hankit avaimen ja teet ensimmäisen testikutsun. Tekoäly nopeuttaa kaikkia näitä vaiheita, mutta avain ja kulut ovat aina sinun vastuullasi.

Yleisin virhe on API-avaimen laittaminen suoraan frontend-koodiin, jolloin avain näkyy jokaisen selaimessa ja sitä voi käyttää väärin. Avain kuuluu ympäristömuuttujaan (.env-tiedosto), ja kutsu tehdään palvelinpuolen route-tiedostosta. Toinen tavallinen ongelma on se, että tekoäly olettaa API:n toimivan tietyllä tavalla ja hallusinoi osoitteen tai parametrin. Korjaus on liittää pyyntöön API:n oikea dokumentaatio ja pyytää tekoälyä noudattamaan sitä. Virheilmoituksen statuskoodi kertoo usein syyn: 401 viittaa avaimeen, 404 väärään osoitteeseen ja 429 liian moneen pyyntöön. Testaa uusi endpoint ennen kuin kytket sen käyttöliittymään. Voit avata osoitteen selaimessa tai kutsua sitä curl-komennolla, ja näet heti, palauttaako se odotetun datan. Näin virhe löytyy oikeasta kerroksesta eikä sitä tarvitse etsiä käyttöliittymän koodista.

REST on yleisin tapa suunnitella web-API, ja endpoint on yksittäinen osoite, johon pyynnön voi lähettää. Esimerkiksi GET /api/products on endpoint, joka palauttaa tuotelistan.