Hvordan mapper HTTP-methods til CRUD, og hvad betyder safe og idempotent?

Eksempler

PUT /users/42 sender hele representationen og erstatter den; PATCH /users/42 sender kun de felter, der skal ændres (fx { "email": "[email protected]" }).

Safe vs. idempotent

Dette er to forskellige egenskaber:

• Safe — metoden ændrer ikke server-state (read-only). GET, HEAD, OPTIONS er safe.
• Idempotent — at lave den samme request N gange har samme effekt som at lave den én gang. GET, PUT, DELETE, HEAD er idempotente.

Hvorfor det betyder noget

Interviewere spørger om dette for at se, om du forstår HTTP-semantik godt nok til at bygge pålidelige APIs. Skellet mellem safe/idempotent er ikke akademisk: det styrer direkte, hvad clients, proxyer og CDN'er må gøre. Safe methods kan caches og prefetches frit; idempotente methods kan automatisk prøves igen (retry) efter en netværks-timeout uden risiko for at duplikere side effects — hvilket er grunden til, at en client sikkert kan prøve en PUT eller DELETE igen, men skal være forsigtig med at prøve en POST igen (den kan oprette to ordrer). Den klassiske fejl er at bruge GET til at udløse side effects (fx GET /users/42/delete), hvilket ødelægger caching og lader crawlere ved et uheld mutere data. At vælge den rigtige method — og respektere dens safe- og idempotency-kontrakt — er det, der gør en API forudsigelig og sikker at bygge tooling omkring.