# Prinsipper Sist oppdatert 10. september 2026 Kilde: https://plas.redia.dk/no/prinsipper/ Beslutningene spesifikasjonen er bygget på, og prinsippene initiativet utvikles etter — ett utsagn og én begrunnelse per prinsipp. PLAS er en spesifikasjon, og de fleste av prinsippene står i den selv. Det første avsnittet gjengir dem slik de står i Provider API v0.6.5. Det andre avsnittet er initiativets prinsipper — hvordan Redia har foreslått at standarden utvikles. De to hører ikke hjemme samme sted, så de står hver for seg. ## Spesifikasjonen Dette fastsetter Provider API v0.6.5 for enhver som implementerer eller kaller det. 1. **Bibliotekssystemet implementerer, produktet kaller.** Provider API er grensesnittet et bibliotekssystem stiller til rådighet, slik at leverandører av biblioteksprodukter møter det samme grensesnittet uansett hvilket system som ligger bak. Det er hele formålet med spesifikasjonen. 2. **Versjonen sendes med, og en ukjent versjon er en feil.** Klienten kan sende `version` på så godt som alle operasjoner; støtter ikke provideren den versjonen, svarer den med feilkode `600`. En versjonsforskjell blir dermed en feil man kan handle på, ikke et felt som mangler. 3. **Ett autentiseringsmønster.** OAuth 2.0 med *client credentials* mot `POST /authentication/oauth2/token`; tokenet sendes som `Bearer` i `Authorization`-headeren, og `401` betyr at det mangler, er ugyldig eller utløpt. Det anbefales at tokenet er et JWT, slik at en tredjepart kan validere det uten å spørre provideren. 4. **Provideren avgjør hvem som kaller.** Spesifikasjonen beskriver to måter å kjenne kunde og leverandør på: en base-URL per bibliotek, eller credentials som bærer begge deler. Valget er providerens — derfor har spesifikasjonen ingen `servers`-blokk, og base-URL-en avtales med provideren. 5. **Ingen HTML i svar.** Et svar inneholder aldri HTML-formaterte data, med mindre operasjonen uttrykkelig sier det. Klienten skal kunne vise innholdet i sin egen flate uten å sanere det først. 6. **Én tidsform.** Tidspunkter er RFC 3339 `date-time` med stor `T` og eksplisitt tidssone — spesifikasjonen antar ingen. Rene datoer er `YYYY-MM-DD`. Ingen unntak, så ingen klient skal gjette. 7. **Parametere er URL-kodede.** Alle URL- og query-parametere forventes kodet ved kallet; en id med komma i en kommaseparert liste blir `%2C`. 8. **Kjente id-er svares, ukjente utelates.** Slår klienten opp en liste av id-er, står de kjente i svaret og de ukjente ikke; er alle ukjente, er svaret et tomt map. Et oppslag feiler ikke fordi én id er feil. 9. **Låntaker-id-er er UUID-er, og låntakerpålogging beskyttes.** Spesifikasjonen anbefaler UUID som `patronId` (en heltalls-id får en UUID ved siden av, og bare den brukes i PLAS) og rate limiting per låntakeridentifikator på `POST /patron/authentication` og `POST /patron/authentication/no-password`. 10. **Spesifikasjonen er fortsatt under arbeid.** Spesifikasjonen sier det selv: felter og struktur kan endre seg. Det er derfor versjonen står på hver side her, og derfor [versjonstabellen](/no/changelog/) skiller mellom *i produksjon* og *i spesifikasjon*. ## Initiativet Dette er Redias forslag til hvordan PLAS utvikles. Standarden tilhører sektoren, så prinsippene gjelder så lenge sektoren tar dem til seg. 1. **Tilgangen standardiseres — ikke systemene.** Kildene fortsetter å være forskjellige; det er veien inn til dem som blir lik. Biblioteket skal ikke bytte system for å få nytte av standarden. 2. **Maskinlesbart først.** Grensesnittet beskrives i OpenAPI, slik at verktøy kan generere klienter og tester direkte fra spesifikasjonen — og slik at dokumentasjonen her kan genereres av den samme filen. 3. **Versjonert, så et bibliotek kan stille krav.** Standarden får utgaver. Et bibliotek kan skrive en bestemt versjon inn i en anskaffelse, og en leverandør kan si nøyaktig hva som støttes. 4. **Domene for domene, i egen takt.** Søk, bibliografiske data, beholdning, låntakerdata, sirkulasjon, fjernlån, digitale medier og felles tjenester beskrives hver for seg. Et bibliotekssystem implementerer dem når det gir mening, og biblioteket kan se hva som støttes. 5. **Åpen dokumentasjon, åpen prosess.** Spesifikasjonen, utgavene og prosessen for nye forslag ligger åpent — det er det dette nettstedet er til for. 6. **Behov før tidsplan.** Standarden begynner med de viktigste felles funksjonene og utvides etter behov fra bibliotek og leverandører, ikke etter en plan lagt på forhånd. 7. **Sektorens standard, ikke én leverandørs.** Bibliotek bidrar med behov, systemleverandører implementerer og former, dataleverandører gjør dataene sine tilgjengelige, og utviklere bygger oppå og foreslår forbedringer. Redia har foreslått PLAS; standarden blir sterk når mange bruker den. ## Når et prinsipp endrer seg Prinsippene i det første avsnittet endrer seg bare når spesifikasjonen gjør det — og da følger denne siden den versjonen som er i produksjon. Prinsippene i det andre avsnittet er initiativets og endres i dialog med sektoren, ikke på denne siden. ## Neste skritt - [Kom i gang](/no/kom-i-gang/) — prinsippene i praksis: base-URL, autentisering, første kall. - [Versjoner og changelog](/no/changelog/) — hvilken versjon av hvert API som er i produksjon, og hva som endret seg. - [Provider API v0.6.5](/no/provider/v0.6.5/) — den delte kontrakten og alle gruppene.