Slik bygger du et REST API: design, sikkerhet og publisering

For å bygge et REST API lister du opp ressursene appen din håndterer (brukere, bestillinger, reservasjoner), gir hver en URL som /orders og /orders/{id}, og bruker HTTP-metoder til handlingene: GET for å lese, POST for å opprette, PATCH for å oppdatere og DELETE for å slette. Returner JSON med meningsfulle statuskoder, valider all input, krev autentisering og tilgangskontroll per post på serveren, og paginer lister. Dokumenter deretter endepunktene og publiser API-et bak HTTPS.

Denne guiden dekker designvalgene, et konkret sett med ruter, forslag til prompts for en AI-appbygger og feilene som skaper sikkerhetshull. Hvis API-er er nytt for deg, start med hva et API er.

Når du trenger et REST API

• Webgrensesnittet ditt må lagre og hente data fra en server
• En mobilapp, partner eller automatiseringsverktøy trenger tilgang til dataene dine
• Andre tjenester sender deg hendelser (webhooks)
• Du deler arbeidet mellom et frontend-team og et backend-team

REST er den vanligste stilen, men ikke den eneste. REST vs GraphQL forklarer når ett fleksibelt spørringsendepunkt passer bedre.

Design først: ressurser og ruter

Skriv ned substantivene i appen din og hva folk gjør med dem. For en enkel bookingapp:

Disse tilsvarer opprett, les, oppdater og slett; se hva CRUD er. Konvensjoner som er verdt å følge:

• Substantiv i flertall, ingen verb i URL-er: /bookings, ikke /getBookings.
• Bare ett nivå med nesting når det tydeliggjør eierskap: /bookings/{id}/notes.
• Handlinger som ikke er CRUD kan være underressurser: POST /bookings/{id}/cancel er tydeligere enn en magisk PATCH.
• Konsistent navngiving av felt, for eksempel created_at overalt.

Statuskoder og feil

Bruk standard HTTP-koder slik at klienter vet hva som skjedde uten å tolke tekst:

Returner feil i ett konsistent JSON-format, for eksempel {"error": {"code": "slot_taken", "message": "Det tidspunktet er ikke lenger ledig."}}, og ta aldri med stack traces eller databasefeil i svarene.

Valg og avveininger

Steg for steg

1. List ressurser og ruter som over, inkludert hvem som kan kalle hver enkelt.
2. Modeller dataene i databasen din med feltene og relasjonene du trenger.
3. Bygg leseruter først, deretter opprett, oppdater og slett.
4. Valider input på hver skriving med et skjemabibliotek: påkrevde felt, typer, lengder, tillatte verdier. Avvis ukjente felt.
5. Legg til autentisering, deretter autorisering per post: å hente /bookings/42 må sjekke at booking 42 tilhører den som kaller, ikke bare at noen er innlogget.
6. Paginer alle lister og sett en øvre grense for sidestørrelse.
7. Begrens antall forespørsler på innlogging og dyre ruter. Se rate limiting.
8. Konfigurer CORS bare hvis nettlesere på andre domener må kalle API-et, og list opp disse opprinnelsene eksplisitt. Slik fikser du CORS-feil forklarer feilene du vil se.
9. Skriv dokumentasjon og tester for hver rute, også for feiltilfellene.
10. Publiser med hemmeligheter i miljøvariabler, HTTPS, logger og en helsesjekk.

Prompts til AI-byggeren din

Stillas:

Lag et REST API for bookinger med disse rutene: GET /api/health, GET /api/bookings (paginert, maks 50 per side), POST /api/bookings, GET /api/bookings/:id, PATCH /api/bookings/:id, DELETE /api/bookings/:id. Lagre data i databasen vår. Valider forespørselskroppene med et skjemabibliotek og avvis ukjente felt. Returner JSON-feil som {"error": {"code", "message"}} med riktige statuskoder (400, 401, 403, 404, 409). Oppbevar hemmeligheter i miljøvariabler.

Sikkerhet:

Krev innlogging på alle booking-ruter. Ved hver lesing, oppdatering og sletting, sjekk på serveren at bookingen tilhører den innloggede brukeren; returner 404 hvis ikke. Aksepter aldri bruker-ID-er eller roller fra forespørselskroppen. Begrens POST /api/bookings til 20 per minutt per bruker. Logg feil på serveren uten å returnere stack traces.

Dokumentasjon:

Skriv en OpenAPI-beskrivelse av disse rutene, og en kort README med eksempler på forespørsler og svar for hver rute.

Teste API-et ditt

Test fra utsiden av frontend, for angripere gjør det:

• Hver rute fungerer med gyldig input og returnerer dokumentert format og kode
• Manglende eller ugyldige felt gir 400 med en tydelig melding
• Ingen token gir 401 på hver beskyttet rute
• Bruker A som ber om bruker Bs post med ID får 404 eller 403
• Lister er paginert; et stort limit begrenses
• Dupliserte eller konfliktfylte opprettelser gir 409, ikke 500
• Grensen for forespørsler gir 429
• Feilsvar inneholder ingen stack traces, SQL eller hemmeligheter
• CORS tillater bare de opprinnelsene du har tenkt

Vanlige feil

• Sjekke innlogging, men ikke eierskap. Det vanligste hullet i API-er: enhver innlogget bruker kan lese hvilken som helst post ved å endre ID-en.
• Stole på klienten. Priser, roller og bruker-ID-er fra forespørselskroppen kan endres.
• Returnere hele databaseradene. Passordhasher og interne felt lekker. Velg hva hvert svar skal inneholde.
• Ubegrensede lister. Én forespørsel for alle postene kan gjøre hele appen treg.
• 200 OK med en feilmelding inni. Klienter og overvåking ser ikke at det feilet.
• CORS satt til å tillate alt på et API som bruker cookies.
• Ingen helsesjekk eller logger, så du får høre om nedetid fra brukerne.

For en bredere gjennomgang før lansering, se sikkerhetssjekklisten for AI-bygde apper.

Bygge et REST API i Mythex

Du kan be Mythex om et API som en del av appen din eller som en egen tjeneste. Dokumentasjonsoppskriften REST API backend har en startprompt: navngi rammeverket og rutene, be om tydelige JSON-feil, oppbevar hemmeligheter i miljøvariabler og ta med en Dockerfile. Container-backender i Node, Python, C#, Java og andre publiseres via en Dockerfile, og Mythex håndterer utrullingen fra Publish (API-backender). Et prosjekt kan kjøre en nettside og en API-server side om side, og du kan bytte mellom dem i forhåndsvisningen. Lagre nøkler som prosjekthemmeligheter, og hvis API-et trenger en database, be om en i chatten. For planlagt arbeid rundt API-et ditt, se hvordan kjøre bakgrunnsjobber.

Spørsmål