Sådan bygger du en REST API: design, sikkerhed og deployment

For at bygge en REST API skal du liste de ressourcer, din app håndterer (brugere, ordrer, bookinger), give hver en URL som /orders og /orders/{id} og bruge HTTP-metoder til handlingerne: GET til at læse, POST til at oprette, PATCH til at opdatere og DELETE til at slette. Returnér JSON med meningsfulde statuskoder, valider al input, kræv login og tilladelseskontrol pr. post på serveren, og paginér lister. Dokumentér derefter endpoints, og deploy API'en bag HTTPS.

Denne guide dækker designbeslutningerne, et gennemarbejdet sæt ruter, prompts til en AI-app-builder og de fejl, der skaber sikkerhedshuller. Hvis API'er er nye for dig, så start med hvad en API er.

Hvornår du har brug for en REST API

• Dit webfrontend skal gemme og hente data fra en server
• En mobilapp, partner eller automationsværktøj skal have adgang til dine data
• Andre tjenester sender dig hændelser (webhooks)
• Du deler arbejdet mellem et frontend- og et backend-team

REST er den mest almindelige stil, men ikke den eneste. REST vs GraphQL forklarer, hvornår ét fleksibelt query-endpoint passer bedre.

Design først: ressourcer og ruter

Skriv de substantiver ned, din app bruger, og hvad folk gør med dem. For en simpel bookingapp:

Disse svarer til create, read, update og delete; se hvad CRUD er. Konventioner, det er værd at følge:

• Flertalsnavneord og ingen verber i URL'er: /bookings, ikke /getBookings.
• Indlejr kun ét niveau, når det gør ejerskab tydeligt: /bookings/{id}/notes.
• Handlinger, der ikke er CRUD, kan være under-ressourcer: POST /bookings/{id}/cancel er tydeligere end et magisk PATCH.
• Ensartede navne på felter, for eksempel created_at alle steder.

Statuskoder og fejl

Brug standard HTTP-koder, så klienter kan se, hvad der skete, uden at tolke tekst:

Returnér fejl i ét ensartet JSON-format, for eksempel {"error": {"code": "slot_taken", "message": "Det tidspunkt er ikke længere ledigt."}}, og inkluder aldrig stack traces eller databasefejl i svar.

Valgmuligheder og afvejninger

Trin for trin

1. Liste ressourcer og ruter som ovenfor, inklusive hvem der må kalde hver enkelt.
2. Modellér dataene i din database med de felter og relationer, du har brug for.
3. Byg læseruterne først, derefter oprette, opdatere og slette.
4. Valider input på hver skrivning med et schema-bibliotek: påkrævede felter, typer, længder, tilladte værdier. Afvis ukendte felter.
5. Tilføj login, derefter autorisation pr. post: at hente /bookings/42 skal tjekke, at booking 42 tilhører kalderen, ikke blot at nogen er logget ind.
6. Paginér alle lister og begræns sidestørrelsen.
7. Begræns antallet af kald til login og dyre ruter. Se rate limiting.
8. Konfigurér CORS kun, hvis browsere på andre domæner skal kalde API'en, og list disse oprindelser eksplicit. Sådan retter du CORS-fejl forklarer de fejl, du vil se.
9. Skriv dokumentation og tests for hver rute, inklusive fejltilfældene.
10. Deploy med hemmeligheder i miljøvariabler, HTTPS, logs og et sundhedstjek.

Prompts til din AI-builder

Stilladsering:

Opret en REST API til bookinger med disse ruter: GET /api/health, GET /api/bookings (pagineret, maks. 50 pr. side), POST /api/bookings, GET /api/bookings/:id, PATCH /api/bookings/:id, DELETE /api/bookings/:id. Gem data i vores database. Valider request-kroppe med et schema-bibliotek, og afvis ukendte felter. Returnér JSON-fejl som {"error": {"code", "message"}} med korrekte statuskoder (400, 401, 403, 404, 409). Behold hemmeligheder i miljøvariabler.

Sikkerhed:

Kræv login på alle booking-ruter. Ved hver læsning, opdatering og sletning skal serveren tjekke, at bookingen tilhører den aktuelle bruger; returnér 404, hvis den ikke gør. Accepter aldrig bruger-ID'er eller roller fra request-kroppen. Begræns POST /api/bookings til 20 pr. minut pr. bruger. Log fejl på serveren uden at returnere stack traces.

Dokumentation:

Skriv en OpenAPI-beskrivelse af disse ruter og en kort README med eksempler på requests og svar for hver enkelt.

Test din API

Test udefra frontenden, for angribere vil gøre det:

• Hver rute virker med gyldig input og returnerer den dokumenterede form og kode
• Manglende eller ugyldige felter giver 400 med en tydelig besked
• Intet token giver 401 på hver beskyttet rute
• Bruger A, der henter bruger B's post via ID, får 404 eller 403
• Lister er paginerede; en enorm limit begrænses
• Dublet- eller konfliktoprettelser giver 409, ikke 500
• Rate limits giver 429
• Fejlsvar indeholder ingen stack traces, SQL eller hemmeligheder
• CORS tillader kun de oprindelser, du har tænkt dig

Almindelige fejl

• Tjekke login, men ikke ejerskab. Det mest almindelige hul i API'er: enhver indlogget bruger kan læse enhver post ved at ændre ID'et.
• Stole på klienten. Priser, roller og bruger-ID'er fra request-kroppen kan redigeres.
• Returnere hele databaserækker. Password-hashes og interne felter lækker. Vælg, hvad hvert svar indeholder.
• Ubegrænsede lister. Én forespørgsel for hver post kan bremse hele appen.
• 200 OK med en fejlbesked i svaret. Klienter og overvågning kan ikke se, at det fejlede.
• CORS sat til at tillade alt på en API, der bruger cookies.
• Ingen sundhedstjek eller logs, så du hører om nedbrud fra brugerne.

Til et bredere tjek før lancering, se sikkerhedstjeklisten for AI-byggede apps.

Sådan bygger du en REST API i Mythex

Du kan bede Mythex om en API som en del af din app eller som sin egen tjeneste. Dokumentationens opskrift REST API-backend har en startprompt: navngiv dit framework og dine ruter, bed om tydelige JSON-fejl, behold hemmeligheder i miljøvariabler, og inkluder en Dockerfile. Container-backends i Node, Python, C#, Java og andre publiceres via en Dockerfile, og Mythex håndterer deployet fra Publish (API-backends). Et projekt kan køre en hjemmeside og en API-server side om side, og du kan skifte mellem dem i forhåndsvisningen. Gem nøgler som projekthemmeligheder, og hvis API'en har brug for en database, så bed om den i chatten. Til planlagt arbejde omkring din API, se sådan kører du baggrundsjobs.

Spørgsmål