Varför AI skippar REST – Sanningen om dina genererade API:er

Du bygger en API med AI-hjälp. Ber den fixa en endpoint för att hämta data. Vad får du? En POST med RPC-stil istället för en enkel GET. Händer hela tiden, eller hur?

Det här mönstret är så vanligt att det väcker frågor. Är det bara slarviga träningsdata, eller döljer sig något mer?

REST är mer filosofi än regelverk

Låt oss inte skylla på AI:n direkt. REST handlar om arkitektoniska riktlinjer, inte stenhårda specifikationer. Det är en tankemodell. Och sådana är svåra för språkmodeller att greppa fullt ut.

REST rekommenderar:

• GET för säkra, oföränderliga läsningar
• POST för att skapa resurser
• HTTP:s semantik i fokus
• Stateless design

Grundat i HTTP:s bästa praxis. Men inget tvingar fram det. Många API:er funkar utmärkt utan REST – och används i produktion dagligen.

Vad AI faktiskt lär sig från datan

Verkligheten är rörig: träningsdatan speglar kaoset. GitHub, Stack Overflow, docs från tusentals projekt. Vad dominerar?

• RPC överallt: Mikrotjänster, GraphQL, gamla system och praktiska lösningar som struntar i renhet
• POST som standard: Enklare validering, utökning och felsökning (POST-loggar skiljer sig från GET)
• Ramar som väljer POST: Många defaultar till det säkra valet
• Säkerhet: Känsliga parametrar göms i body, inte URL

Statistiskt sett känns POST som det flexibla valet. AI:n följer bara vad den ser mest av i verklig kod.

Tokenkostnaden spelar roll

Enklare förklaring: tokens räknas.

RPC-exempel:

POST /api/users
{ "action": "getUser", "id": 123 }

REST-variant:

GET /api/users/123

AI genererar token för token. Färre val, kortare endpoints – mindre jobb. Inte huvudorsaken, men en faktor.

REST:s svagheter som AI kanske sniffar upp

REST passar inte alltid. GraphQL löser fasta svarsstrukturer. Query-språk hanterar komplexa sökningar bättre än URL:er. Interna tjänster slopar REST när fördelarna uteblir.

Kanske lär sig AI:n att REST är kontextberoende? Perfekt för publika API:er och klient-server, men overkill internt. Inte att REST är fel – bara inte alltid bäst.

Vad ligger bakom, egentligen?

En mix, troligen:

1. Dataskevning: Icke-REST dominerar i verkligheten
2. Abstraktionsproblem: Filosofi kodas svårare än syntax
3. Effektivitet: Enklare generering sparar tokens
4. Kontextkännedom: Modellerna noterar REST:s gränser

Så får du REST av din AI

Var tydlig i prompten:

Skapa en RESTful endpoint efter bästa praxis. 
GET för läsning, rätt HTTP-koder. 
Modell: User { id, name, email }

Ju mer specifikt, desto bättre resultat. Prompt engineering för API:er.

Slutsatsen

AI förkastar inte REST av ren envishet. Den speglar hur kod skrivs ute i det verkliga. REST är elegant – men ett val bland flera. Välj det när det passar: publika API:er, webbläsare, distribuerade system. Annars vinner pragmatism.

Din AI har redan fattat det. Kanske dags för oss att haka på.

Vill du ha produktionsklara API:er i nästa projekt? NameOcean:s Vibe Hosting har AI-verktyg som lär sig dina preferenser. Sätt mönster en gång, och genereringen anpassar sig. Läs mer om smartare utveckling med NameOcean.