De flesta API-“docs” är egentligen inte specifikationer. De är halvt vägledning, halvt intern kunskap, och de faller ihop så fort ett andra team försöker bygga mot dem. Du får endpoints som känns slumpmässiga, statuskoder som inte matchar verkligheten och felresponser som tvingar alla att lägga till speciallogik.
Den här REST API specs är byggd för produktchefer som vill synka backend och frontend innan utvecklingen börjar, plattformsingenjörer som städar upp en växande uppsättning inkonsekventa endpoints och lösningskonsulter som behöver tydliga kontrakt för kundintegrationer. Resultatet är en komplett REST API-blåkopi: resursmodeller, endpoint-tabeller, request/response-payloads, statuskoder, headers, pagineringsregler, felkontrakt och en versioneringsstrategi du kan implementera.
Vad gör den här AI-prompten och när ska du använda den?
| Vad den här prompten gör | När du ska använda den här prompten | Det du får |
|---|---|---|
|
|
|
Hela AI-prompten: blåkopi för specifikation av REST API-endpoints
Fyll i fälten nedan för att anpassa prompten efter dina behov.
| Variabel | Vad du ska ange | Anpassa prompten |
|---|---|---|
[MALGRUPP] |
Beskriv API:ets primära användare eller konsumenter, inklusive deras roller, tekniska kompetens och användningsfall. Till exempel: "Frontend- och backendutvecklare som bygger integrationer för en B2B SaaS-plattform, med medelgod kunskap om REST-API:er."
|
|
[HUVUDRESURS] |
Definiera den centrala resurs som API:et ska hantera, inklusive syfte och viktigaste attribut. Till exempel: "Ordrar: Representerar en kunds köp, inklusive detaljer som artiklar, antal, priser och leveransinformation."
|
|
[NODVANDIGA_ATGARDER] |
Lista de viktigaste åtgärderna som användare behöver kunna utföra på huvudresursen, till exempel skapa, läsa, uppdatera eller radera. Till exempel: "Skapa nya ordrar, hämta orderdetaljer, uppdatera orderstatus, radera avbrutna ordrar."
|
|
[AUTENTISERINGSKRAV] |
Specificera modell för autentisering och behörighet, inklusive tokentyper, scopes och roller som krävs för åtkomst. Till exempel: "OAuth 2.0 med bearer tokens; roller inkluderar administratör, kund och supportagent med olika åtkomstnivåer."
|
|
[DATAFORMAT] |
Definiera förväntade payload-format för förfrågningar och svar, inklusive headers och serialiseringsformat. Till exempel: "JSON för alla payloads; headers inkluderar `Content-Type: application/json` och `Accept: application/json`."
|
|
[RELATERADE_RESURSER] |
Identifiera andra resurser som interagerar med eller är kopplade till huvudresursen, och beskriv relationerna mellan dem. Till exempel: "Kunder och produkter: Ordrar är kopplade till kunder som lägger dem och produkter som ingår i ordern."
|
|
[KONTEXT] |
Ge relevant bakgrund eller begränsningar som påverkar API-designen, till exempel affärsmål eller tekniska begränsningar. Till exempel: "API:et måste stödja multi-tenancy för företagskunder och hantera höga transaktionsvolymer under högtrafik."
|
|
[TIDSRAM] |
Ange förväntad tidsplan för att färdigställa API-designen samt eventuella milstolpar. Till exempel: "Inledande design och endpointspecifikationer ska levereras inom 4 veckor; full implementation inom 3 månader."
|
Proffstips för bättre resultat med AI-prompten
- Definiera konsumenten först, inte databasen. Innan du kör prompten: skriv ett stycke om vem som anropar API:et och vad de försöker göra, med vanlig svenska. Klistra sedan in det ovanför din resursbeskrivning och be: “Modellera API:et för externa konsumenter; spegla inte interna tabeller.” Du får mer strukturerade resurser och färre “läckande” fält.
- Ge 3–5 verkliga operationer som acceptanskriterier. Om du bara säger “CRUD” blir specen generisk. Ge scenarier som “En användare kan lista fakturor filtrerade på status och datumintervall” eller “Support kan makulera en faktura med en orsakskod”, och följ upp med: “Mappa nu dessa scenarier till endpoints och motivera verb och statuskod för varje.”
- Tvinga fram konsekvens med ett test av felkontraktet. När du fått första utkastet, fråga: “Skapa en feltaxonomi för detta API och visa exakt JSON-struktur för varje kategori; säkerställ att varje endpoint refererar till den.” Ärligt talat: det här enda steget kan spara veckor av klientnära edge cases.
- Iterera på namngivning och nästning, inte bara payload-fält. Efter första output, prova att fråga: “Skriv om endpoints för att minska nästningsdjupet om det inte tillför betydelse; om du behåller nästning, förklara varför.” Fråga sedan: “Lista eventuella endpoints som känns som actions och föreslå resursalternativ.”
- Gör om blåkopian till implementeringsklara checklistor. När specen känns stabil, prompta: “För varje endpoint: ta fram en checklista för backend-implementering (validering, auth-kontroller, idempotens, rate limits, loggning/correlation id) och en checklista för frontend/klient (felhantering, retries, paginering).” Då blir specen en konkret byggplan.
Vanliga frågor
API- och plattformsingenjörer använder den för att införa konsekventa mönster (verb, statuskoder, felstrukturer, paginering) över endpoints så att klienter kan “gissa” beteendet. Produktchefer använder den för att omvandla krav till konkreta kontrakt som underlättar estimat och samsyn mellan team. Lösningsarkitekter och konsulter använder den när de behöver en integrationsspec mot kund som inte avslöjar interna implementationsdetaljer. Tech leads har nytta av den i granskningar eftersom den tvingar fram tydliga beslut om versionering, nästning och konsekvens i response.
SaaS-bolag får värde eftersom ett förutsägbart publikt API minskar supportärenden och förbättrar tiden till första integration för partners. Det är särskilt användbart när flera klienter använder samma endpoints (webbapp, mobilapp, integrationer) och inkonsekvens skapar regressioner. E-handel och marknadsplatser gynnas när man modellerar ordrar, återbetalningar, leveranser och returer, där konflikthantering (409/422) och idempotenta operationer spelar roll i praktiken. Fintech-team använder den för att definiera säkra, granskningsbara mönster för betalningar, utbetalningar och tvister, inklusive tydliga felkontrakt och rate-limit-responser. Hälso- och compliance-tunga appar uppskattar kravet “läck inte interna detaljer”, vilket hjälper till att hålla payloads stabila och säkrare för externa konsumenter.
En typisk prompt som ”Skriv ett REST API för fakturor” misslyckas eftersom den: saknar ett föranalyssteg som låser den primära resursen, relationer och operationer; ger inget konsekvent ramverk för verb, koder och headers över endpoints; ignorerar konventioner för paginering/filtrering/sortering så att varje list-endpoint blir en egen speciallösning; producerar generiska svar i stället för konkreta request/response-exempel med ett tydligt felkontrakt; och missar skyddsräcken för versionering och “läck inte interna detaljer” som håller ett API stabilt för verkliga konsumenter.
Ja, men du gör anpassningen genom att ge bättre kontext kring den primära resursen, nödvändiga operationer, relaterade resurser och den auth-modell du förväntar dig att klienter använder. Lägg till begränsningar som “måste stödja idempotens för POST”, “multi-tenant-scope krävs” eller “publikt partner-API vs internt API”, så förändras blåkopian på meningsfulla sätt. Efter första körningen kan du följa upp med något som: “Revidera specen utifrån OAuth2 client credentials och lägg till rate limiting samt en correlation-id-header i varje response.” Om du redan har delar av endpoints, klistra in dem och be: “Normalisera dessa enligt standardkonventionerna i blåkopian och lista brytande ändringar.”
Det största misstaget är att lämna den primära resursen vag — i stället för “användare”, säg “workspace-medlemmar med roller, inbjudna vs aktiva tillstånd och en unik e-post per workspace.” Ett annat vanligt fel är att bara lista CRUD-operationer; bättre input är “skapa faktura, slutför faktura, makulera faktura med orsak, lista fakturor filtrerade på status/datum, ladda ner PDF.” Många glömmer också att specificera auth-modellen, vilket leder till felaktiga antaganden (dåligt: “säkra den”, bättre: “bearer token; tenant scoped via workspace_id; beteende för 403 vs 404 ska vara konsekvent”). Slutligen hoppar team över relationer; “fakturor tillhör kunder” går att agera på, medan “fakturor relaterar till grejer” ger rörig nästning och otydliga URL:er.
Den här prompten är inte optimal för engångsskript internt där ingen annan ska integrera och långsiktig konsekvens inte spelar någon roll. Den passar heller inte om du behöver att en komplett OpenAPI/Swagger-fil genereras automatiskt med scheman och exempel kopplade till components; detta ger en blåkopi som är enkel att konvertera, inte ett färdigt spec-artefakt. Och om du inte har validerat vilka operationer produkten faktiskt behöver riskerar du att dokumentera endpoints som bygger på gissningar. I så fall: gör en kort discovery först och kom tillbaka med verkliga scenarier och constraints.
Felfria API:er uppstår inte av en slump. Använd den här prompten för att ta fram REST endpoint-specar som teamen kan implementera, granska och konsumera med betydligt mindre fram och tillbaka.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.