Provider API v0.6.5

Provider API’et er PLAS’ hovedflade. Implementerer et bibliotekssystem det, kan ethvert produkt der taler PLAS arbejde med biblioteket uden at kende systemet underneden — og et produkt der er bygget mod ét bibliotek virker hos det næste.

Fladen dækker det et bibliotek gør hver dag: låneren og hendes samtykker, lån og fornyelser, reserveringer, gebyrer og betaling, beholdning og lokationer, checkout og checkin, søgning i katalogets værker og udgivelser, og de arrangementer biblioteket udgiver. Hver del har sin egen gruppe i menuen.

Sådan integrerer du

Der er tre ting du skal have på plads, og de står i den rækkefølge du møder dem:

1. Base-URL’en. Specifikationen har ingen servers-blok, så adressen er providerens og aftales med den. Regn ikke med at den er den samme fra bibliotek til bibliotek, heller ikke hos samme provider.
2. Et token. POST /authentication/oauth2/token med client_id, client_secret og grant_type=client_credentials giver et Bearer-token, som sendes med på alle øvrige kald.
3. Versionen. Send version som query-parameter på hvert kald. Understøtter provideren den ikke, får du fejlkode 600 — altså en fejl du kan handle på, frem for et svar der ser rigtigt ud.

Det ene kald der hverken kræver token eller aftale er GET /version. Start dér: svarer den, er base-URL’en rigtig. Hele vejen igennem, med eksempler, står i Kom i gang.

Forholdet til de andre API’er

Search API og Content API er profiler af denne flade: hver eneste af deres operationer findes her, med samme operationId, metode og sti. De findes for at et system kan implementere ét område alene — søgning eller arrangementer — uden at implementere hele Provider API’et. Implementerer du Provider, har du allerede dem begge.

Vendor Consumer API er derimod den modsatte retning: den flade dit eget produkt stiller til rådighed, så bibliotekssystemet kan sende noget til dig.