{"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/api","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/cs/api/","da":"https://cmaintz.github.io/tech-atlas/da/terms/cs/api/"},"term":{"en":"API","da":"API"},"aka":{"en":["application programming interface"],"da":["programmeringsgrænseflade"]},"domain":["cs"],"cluster":"web","layer":"application","status":"current","era":1968,"summary":{"en":"A fixed set of requests one program offers so other programs can use its data or features without seeing its insides.","da":"Et fast sæt forespørgsler, som et program tilbyder, så andre programmer kan bruge dets data og funktioner uden at se indmaden."},"body":{"formal":{"en":"A published contract that names the operations a piece of software accepts, the input each one expects and the output it returns; on the web this usually means a server answering HTTP requests with structured data rather than pages.","da":"En offentliggjort kontrakt, der angiver, hvilke operationer et stykke software tager imod, hvilket input hver forventer, og hvilket output den returnerer; på nettet betyder det typisk en server, der svarer på HTTP-forespørgsler med strukturerede data frem for sider."},"plain":{"en":"Like the menu and the waiter in a restaurant - you order from a fixed list, the kitchen does the work, and you never need to know how it is cooked.","da":"Som menukortet og tjeneren på en restaurant - du bestiller fra en fast liste, køkkenet gør arbejdet, og du behøver aldrig vide, hvordan maden laves."},"inPractice":{"en":"Every night a municipality's payroll system asks the HR system's API for new and departing staff, and gets back names, start dates and pay grades, so nobody has to type them in twice.","da":"Hver nat spørger kommunens lønsystem HR-systemets API om nye og fratrådte medarbejdere og får navne, startdatoer og løntrin tilbage, så ingen skal taste dem ind to gange."},"whyItMatters":{"en":"APIs let separate systems be built and changed on their own and still work together, but each one is also a door that must check who is knocking and what they ask for.","da":"API'er lader adskilte systemer blive bygget og ændret hver for sig og stadig arbejde sammen, men hvert API er også en dør, der skal tjekke, hvem der banker på, og hvad de beder om."}},"deepDive":{"en":"The term covers two different layers. A library or operating-system API (POSIX, Win32, a language's standard library) is a source-level contract resolved at compile or link time, and it is distinct from the ABI, the binary contract of calling conventions and data layout that decides whether compiled code still links after an upgrade. A network API is a contract over a wire protocol. On the web the dominant styles are resource-oriented REST over HTTP, RPC styles such as gRPC (Protocol Buffers over HTTP/2) and JSON-RPC 2.0, GraphQL with a single endpoint and client-chosen selection sets, and event-driven interfaces such as webhooks. Contracts are written down in machine-readable form: OpenAPI documents for HTTP APIs, .proto files for gRPC, the GraphQL schema definition language, AsyncAPI for event interfaces.\n\nEvolving an API without breaking its consumers is the central engineering problem. Adding optional fields is compatible only if clients ignore unknown fields (the tolerant reader pattern); removing, renaming or changing the type of a field breaks them. Providers version in the path (/v2), in a header or in the media type, and signal retirement with the Sunset header (RFC 8594). Hyrum's law captures the limit of all contracts: with enough users, every observable behaviour, including undocumented ordering or error text, will be depended on by someone. Operational semantics belong to the contract too: pagination, rate limits answered with 429 Too Many Requests (RFC 6585) and Retry-After, and idempotency keys that make retries of non-idempotent POST requests safe.\n\nThe OWASP API Security Top 10 (2023 edition) shows where APIs fail: API1 Broken Object Level Authorization, where the server accepts an object ID from the client without checking ownership; API3 Broken Object Property Level Authorization, covering mass assignment and excessive data exposure; API5 Broken Function Level Authorization; API4 Unrestricted Resource Consumption; and API9 Improper Inventory Management, meaning forgotten old versions and undocumented \"shadow\" endpoints. Authentication ranges from API keys, which identify an application but rarely a user and tend to leak, through OAuth 2.0 bearer tokens (RFC 6750) and JWT access tokens that must be validated for issuer, audience and expiry, to mutual TLS with certificate-bound tokens (RFC 8705).\n\nAn API should not be confused with its neighbours: a protocol (HTTP) is the transport the API uses, an endpoint is one addressable operation within it, an SDK is a client library wrapping it, and an API gateway is infrastructure in front of it that handles routing, authentication and rate limiting, but cannot enforce object-level authorisation, which requires business knowledge only the API itself has.","da":"Begrebet dækker to forskellige lag. Et biblioteks- eller styresystem-API (POSIX, Win32, et sprogs standardbibliotek) er en kontrakt på kildekodeniveau, som afgøres ved kompilering eller linkning, og det er forskelligt fra ABI'en, den binære kontrakt om kaldkonventioner og datalayout, der afgør, om kompileret kode stadig kan linkes efter en opgradering. Et netværks-API er en kontrakt over en protokol. På nettet er de dominerende stilarter ressourceorienteret REST over HTTP, RPC-stilarter som gRPC (Protocol Buffers over HTTP/2) og JSON-RPC 2.0, GraphQL med ét endpoint og felter, som klienten selv vælger, samt hændelsesdrevne grænseflader som webhooks. Kontrakterne skrives ned i maskinlæsbar form: OpenAPI-dokumenter til HTTP-API'er, .proto-filer til gRPC, GraphQL's schema definition language og AsyncAPI til hændelsesgrænseflader.\n\nAt videreudvikle et API uden at ødelægge det for forbrugerne er det centrale tekniske problem. Nye valgfrie felter er kun kompatible, hvis klienterne ignorerer ukendte felter (tolerant reader-mønsteret); at fjerne, omdøbe eller ændre typen på et felt bryder dem. Udbydere versionerer i stien (/v2), i en header eller i medietypen og varsler udfasning med Sunset-headeren (RFC 8594). Hyrums lov beskriver grænsen for alle kontrakter: med nok brugere vil nogen afhænge af enhver observerbar adfærd, også udokumenteret rækkefølge eller fejltekster. Driftssemantik hører også til kontrakten: paginering, rate limiting besvaret med 429 Too Many Requests (RFC 6585) og Retry-After samt idempotensnøgler, der gør gentagelse af ikke-idempotente POST-kald sikker.\n\nOWASP API Security Top 10 (udgaven fra 2023) viser, hvor API'er fejler: API1 Broken Object Level Authorization, hvor serveren accepterer et objekt-id fra klienten uden at tjekke ejerskab; API3 Broken Object Property Level Authorization, som dækker mass assignment og for meget data i svarene; API5 Broken Function Level Authorization; API4 Unrestricted Resource Consumption; og API9 Improper Inventory Management, dvs. glemte gamle versioner og udokumenterede \"shadow\"-endpoints. Autentificering spænder fra API-nøgler, der identificerer en applikation, men sjældent en bruger, og som ofte lækker, over OAuth 2.0-bearer tokens (RFC 6750) og JWT-adgangstokens, der skal valideres for udsteder, modtager og udløb, til gensidig TLS med certifikatbundne tokens (RFC 8705).\n\nEt API må ikke forveksles med naboerne: en protokol (HTTP) er den transport, API'et bruger, et endpoint er én adresserbar operation i det, et SDK er et klientbibliotek, der pakker det ind, og en API-gateway er infrastruktur foran det, der står for routing, autentificering og rate limiting, men ikke kan håndhæve autorisation på objektniveau, fordi det kræver forretningsviden, som kun API'et selv har."},"edges":[{"type":"requires","to":"cs/client","confidence":"high","strength":"normal"},{"type":"requires","to":"cs/server","confidence":"high","strength":"normal"},{"type":"used-with","to":"cs/http","why":{"en":"Most APIs on the web take requests and send answers over HTTP.","da":"De fleste API'er på nettet tager imod forespørgsler og sender svar over HTTP."},"confidence":"high","strength":"primary"},{"type":"used-with","to":"cs/web-application","confidence":"high","strength":"normal"},{"type":"used-with","to":"cs/json","why":{"en":"APIs commonly send and receive their data as JSON.","da":"API'er sender og modtager typisk deres data som JSON."},"confidence":"high","strength":"normal"}],"depth":4,"sources":[{"title":"MDN Web Docs - Glossary, API","url":"https://developer.mozilla.org/en-US/docs/Glossary/API","tier":"official-doc","publisher":"Mozilla"},{"title":"RFC 9110 - HTTP Semantics","url":"https://www.rfc-editor.org/rfc/rfc9110","tier":"standard","publisher":"IETF"}],"draft":true}