Så bygger du ett REST API: design, säkerhet och driftsättning

För att bygga ett REST API listar du de resurser din app hanterar (användare, ordrar, bokningar), ger var och en en URL som /orders och /orders/{id}, och använder HTTP-metoder för åtgärderna: GET för att läsa, POST för att skapa, PATCH för att uppdatera och DELETE för att ta bort. Returnera JSON med tydliga statuskoder, validera varje indata, kräv inloggning och behörighetskontroller per post på servern, och paginera listor. Dokumentera sedan endpoints och driftsätt API:et bakom HTTPS.

Guiden tar upp designbeslut, en genomarbetad uppsättning rutter, prompter till en AI-appbyggare och de misstag som orsakar säkerhetshål. Om API:er är nytt för dig, börja med vad ett API är.

När du behöver ett REST API

• Din webbfrontend behöver spara och hämta data från en server
• En mobilapp, partner eller ett automationsverktyg behöver åtkomst till din data
• Andra tjänster skickar händelser till dig (webhooks)
• Du delar upp arbetet mellan ett frontend- och ett backendteam

REST är den vanligaste stilen, men inte den enda. REST vs GraphQL förklarar när en enda flexibel frågeendpoint passar bättre.

Designa först: resurser och rutter

Skriv ner substantiven i din app och vad folk gör med dem. För en enkel bokningsapp ser det ut så här:

Dessa motsvarar skapa, läsa, uppdatera och ta bort; se vad CRUD är. Konventioner värda att följa:

• Substantiv i plural, inga verb i URL:er: /bookings, inte /getBookings.
• Nästla bara en nivå när det tydliggör ägarskap: /bookings/{id}/notes.
• Åtgärder som inte är CRUD kan vara under-resurser: POST /bookings/{id}/cancel är tydligare än en magisk PATCH.
• Konsekvent namngivning av fält, till exempel created_at överallt.

Statuskoder och fel

Använd standardkoder för HTTP så att klienter vet vad som hände utan att tolka text:

Returnera fel i ett konsekvent JSON-format, till exempel {"error": {"code": "slot_taken", "message": "Den tiden är inte längre ledig."}}, och ta aldrig med stacktraces eller databasfel i svaren.

Alternativ och avvägningar

Steg för steg

1. Lista resurser och rutter som ovan, inklusive vem som får anropa varje rutt.
2. Modellera datan i din databas med de fält och relationer du behöver.
3. Bygg läsrutter först, sedan skapa, uppdatera och ta bort.
4. Validera indata vid varje skrivning med ett schemabibliotek: obligatoriska fält, typer, längder och tillåtna värden. Avvisa okända fält.
5. Lägg till inloggning, sedan behörighet per post. Att öppna /bookings/42 måste kontrollera att bokning 42 tillhör anroparen, inte bara att någon är inloggad.
6. Sidindela varje lista och begränsa sidstorleken.
7. Begränsa antalet anrop för inloggning och dyra rutter. Se rate limiting.
8. Konfigurera CORS bara om webbläsare på andra domäner måste anropa API:et, och lista de origin:erna uttryckligen. Så åtgärdar du CORS-fel förklarar felen du kommer att se.
9. Skriv dokumentation och tester för varje rutt, inklusive felfallen.
10. Driftsätt med hemligheter i miljövariabler, HTTPS, loggar och en hälsokontroll.

Prompter till din AI-byggare

Skapa:

Skapa ett REST API för bokningar med dessa rutter: GET /api/health, GET /api/bookings (sidindelat, max 50 per sida), POST /api/bookings, GET /api/bookings/:id, PATCH /api/bookings/:id, DELETE /api/bookings/:id. Lagra data i vår databas. Validera request-bodyn med ett schemabibliotek och avvisa okända fält. Returnera JSON-fel som {"error": {"code", "message"}} med rätt statuskoder (400, 401, 403, 404, 409). Håll hemligheter i miljövariabler.

Säkerhet:

Kräv inloggning på varje bokningsrutt. Vid varje läsning, uppdatering och borttagning, kontrollera på servern att bokningen tillhör den aktuella användaren; returnera 404 om den inte gör det. Acceptera aldrig användar-ID:n eller roller från request-bodyn. Begränsa POST /api/bookings till 20 per minut och användare. Logga fel på servern utan att returnera stacktraces.

Dokumentation:

Skriv en OpenAPI-beskrivning av dessa rutter och en kort README med exempelanrop och svar för varje rutt.

Testa ditt API

Testa utifrån, eftersom angripare kommer att göra det:

• Varje rutt fungerar med giltig indata och returnerar dokumenterad form och kod
• Saknade eller ogiltiga fält ger 400 med ett tydligt meddelande
• Ingen token ger 401 på varje skyddad rutt
• Användare A som begär användare B:s post via ID får 404 eller 403
• Listor är sidindelade, och ett stort limit begränsas
• Dubbletter eller konflikter vid skapande ger 409, inte 500
• Gränser för antal anrop ger 429
• Felsvar innehåller inga stacktraces, SQL eller hemligheter
• CORS tillåter bara de origin:er du avser

Vanliga misstag

• Kontrollera inloggning men inte ägarskap. Det vanligaste API-hålet: vilken inloggad användare som helst kan läsa vilken post som helst genom att ändra ID:t.
• Lita på klienten. Priser, roller och användar-ID:n i request-bodyn kan ändras.
• Returnera hela databasrader. Lösenordshashar och interna fält läcker. Välj vad varje svar innehåller.
• Obegränsade listor. Ett anrop för varje post kan göra hela appen långsam.
• 200 OK med ett felmeddelande i svaret. Klienter och övervakning kan inte se att något gick fel.
• CORS satt till att tillåta allt på ett API som använder cookies.
• Ingen hälsokontroll eller loggar, så att du får veta om avbrott från användare.

För en bredare genomgång före lansering, se säkerhetschecklistan för AI-byggda appar.

Bygga ett REST API i Mythex

Du kan be Mythex om ett API som en del av din app eller som en egen tjänst. Dokumentationens recept REST API-backend har en startprompt: ange ramverk och rutter, be om tydliga JSON-fel, håll hemligheter i miljövariabler och ta med en Dockerfile. Containerbackends i Node, Python, C#, Java och andra publiceras via en Dockerfile, och Mythex sköter driftsättningen från Publicera (API-backends). Ett projekt kan köra en webbplats och en API-server sida vid sida, och du kan växla mellan dem i förhandsvisningen. Spara nycklar som projekthemligheter, och om API:et behöver en databas, be om den i chatten. För schemalagt arbete kring ditt API, se så kör du bakgrundsjobb.

Frågor