{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"cs/rest-api","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/cs/rest-api/","da":"https://cmaintz.github.io/tech-atlas/da/terms/cs/rest-api/"},"term":{"en":"REST API","da":"REST API"},"aka":{"en":["RESTful API"],"da":["RESTful API"]},"domain":["cs"],"cluster":"web","layer":"application","status":"current","era":2000,"summary":{"en":"A common style of web API where each thing has its own URL and programs use plain HTTP methods to read, add, change or delete it.","da":"En udbredt slags web-API, hvor hver ting har sin egen URL, og programmer læser, tilføjer, ændrer eller sletter den med HTTP-metoder."},"body":{"formal":{"en":"An API that follows the REST style described by Roy Fielding in 2000 - each resource has its own URL, HTTP methods such as GET, POST, PUT and DELETE say what to do with it, and the server keeps no memory of the client between requests.","da":"Et API, der følger REST-stilen, som Roy Fielding beskrev i 2000 - hver ressource har sin egen URL, HTTP-metoder som GET, POST, PUT og DELETE siger, hvad der skal ske med den, og serveren husker ikke klienten mellem forespørgslerne."},"plain":{"en":"Like a library where every book has a fixed shelf number, and there are only a handful of desk requests - borrow, return, add, remove - that work the same for every book.","da":"Som et bibliotek, hvor hver bog har et fast hyldenummer, og der kun er en håndfuld ting, man kan bede om ved skranken - låne, aflevere, tilføje, fjerne - som virker ens for alle bøger."},"inPractice":{"en":"A ferry company's booking app sends GET to the address for booking 42 to show its status, and DELETE to the same address when the passenger cancels the trip.","da":"Et rederis bookingapp sender GET til adressen for booking 42 for at vise dens status og DELETE til samme adresse, når passageren aflyser turen."},"whyItMatters":{"en":"Its simple, shared rules let any team build a client without special tools; each address is also a door into the system, so every one needs its own access checks.","da":"Dens enkle, fælles regler lader ethvert team bygge en klient uden særlige værktøjer; hver adresse er samtidig en dør ind i systemet, så hver enkelt skal have sin egen adgangskontrol."}},"deepDive":{"en":"In chapter 5 of his 2000 dissertation Roy Fielding derives REST by adding constraints one at a time: client-server, stateless (each request carries everything needed to understand it), cacheable responses, a uniform interface, a layered system and optional code-on-demand. The uniform interface has four sub-constraints: identification of resources, manipulation of resources through representations, self-descriptive messages, and hypermedia as the engine of application state (HATEOAS), meaning clients discover next actions from links in responses rather than from out-of-band knowledge. Most APIs marketed as REST ignore hypermedia, which Fielding criticised publicly in 2008; the Richardson Maturity Model grades APIs from level 0 (one endpoint, RPC over HTTP) through resources and HTTP verbs to level 3 (hypermedia controls).\n\nThe conventional mapping uses HTTP semantics directly. GET retrieves and is safe and cacheable; POST to a collection creates a subordinate resource, answering 201 Created with a Location header, and is not idempotent; PUT replaces a resource and is idempotent; PATCH (RFC 5789) applies a partial change, expressed either as JSON Merge Patch (RFC 7396) or as a JSON Patch operation list (RFC 6902); DELETE removes. Lost updates are prevented with ETags and If-Match, answered with 412 Precondition Failed on conflict. Errors are increasingly returned as problem details (application/problem+json, RFC 9457, which obsoleted RFC 7807), and pagination uses cursors or Link headers (RFC 8288). Because POST is not idempotent, safe retries require an idempotency key agreed between client and server.\n\nContracts are described with the OpenAPI Specification, which grew out of Swagger 2.0 and was donated to the Linux Foundation's OpenAPI Initiative in 2015; version 3.1 aligned its schema dialect with JSON Schema 2020-12. The description drives documentation, client code generation, contract testing and request validation at gateways.\n\nThe resource-per-URL design makes object identifiers visible in every request, which is why Broken Object Level Authorization is API1 in the OWASP API Security Top 10 (2023): changing /bookings/42 to /bookings/43 must be refused by an ownership check on the server, and switching to UUIDs only makes guessing harder without fixing the flaw. PUT and PATCH endpoints that bind the request body straight onto a data model enable mass assignment of fields such as isAdmin (part of API3:2023), and method-override headers such as X-HTTP-Method-Override can bypass access rules written per HTTP method. REST contrasts with GraphQL, where one endpoint accepts client-shaped queries, and with gRPC, which exposes procedures rather than resources.","da":"I kapitel 5 af sin afhandling fra 2000 udleder Roy Fielding REST ved at tilføje begrænsninger én ad gangen: klient-server, tilstandsløshed (hver forespørgsel indeholder alt, hvad der skal til for at forstå den), svar der kan caches, en ensartet grænseflade, et lagdelt system og valgfri code-on-demand. Den ensartede grænseflade har fire delkrav: identifikation af ressourcer, behandling af ressourcer via repræsentationer, selvbeskrivende beskeder og hypermedie som motor for applikationens tilstand (HATEOAS), dvs. at klienter finder de næste handlinger via links i svarene frem for via viden udefra. De fleste API'er, der markedsføres som REST, ignorerer hypermedie, hvilket Fielding offentligt kritiserede i 2008; Richardson Maturity Model inddeler API'er fra niveau 0 (ét endpoint, RPC over HTTP) over ressourcer og HTTP-verber til niveau 3 (hypermediekontroller).\n\nDen gængse kortlægning bruger HTTP's semantik direkte. GET henter og er sikker og kan caches; POST til en samling opretter en underordnet ressource, svarer med 201 Created og en Location-header og er ikke idempotent; PUT erstatter en ressource og er idempotent; PATCH (RFC 5789) anvender en delvis ændring, udtrykt enten som JSON Merge Patch (RFC 7396) eller som en liste af JSON Patch-operationer (RFC 6902); DELETE fjerner. Tabte opdateringer forhindres med ETags og If-Match, besvaret med 412 Precondition Failed ved konflikt. Fejl returneres i stigende grad som problem details (application/problem+json, RFC 9457, som afløste RFC 7807), og paginering bruger cursorer eller Link-headere (RFC 8288). Fordi POST ikke er idempotent, kræver sikre gentagelser en idempotensnøgle, som klient og server er enige om.\n\nKontrakterne beskrives med OpenAPI Specification, der voksede ud af Swagger 2.0 og blev overdraget til Linux Foundations OpenAPI Initiative i 2015; version 3.1 afstemte sin skemadialekt med JSON Schema 2020-12. Beskrivelsen driver dokumentation, generering af klientkode, kontrakttest og validering af forespørgsler i gateways.\n\nDesignet med én URL pr. ressource gør objekt-id'er synlige i hver forespørgsel, og derfor er Broken Object Level Authorization API1 i OWASP API Security Top 10 (2023): at ændre /bookings/42 til /bookings/43 skal afvises af en ejerskabskontrol på serveren, og at skifte til UUID'er gør kun gætteriet sværere uden at rette fejlen. PUT- og PATCH-endpoints, der binder forespørgslens indhold direkte på en datamodel, åbner for mass assignment af felter som isAdmin (en del af API3:2023), og headere til metodeoverstyring som X-HTTP-Method-Override kan omgå adgangsregler skrevet pr. HTTP-metode. REST står i kontrast til GraphQL, hvor ét endpoint modtager forespørgsler formet af klienten, og til gRPC, der udstiller procedurer frem for ressourcer."},"edges":[{"type":"requires","to":"cs/http","confidence":"high","strength":"normal"},{"type":"requires","to":"cs/url","confidence":"high","strength":"normal"},{"type":"kind-of","to":"cs/api","confidence":"high","strength":"normal"}],"depth":6,"sources":[{"title":"Roy T. Fielding - Architectural Styles and the Design of Network-based Software Architectures (Chapter 5, REST)","url":"https://ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm","tier":"reference","publisher":"University of California, Irvine"},{"title":"MDN Web Docs - Glossary, REST","url":"https://developer.mozilla.org/en-US/docs/Glossary/REST","tier":"official-doc","publisher":"Mozilla"}],"draft":true}