OBS: Denne side vedrører kun version 2 af API’et. Søger du generel information eller version 1 information bedes du læse API Design (V1)
Table of Contents | ||||
---|---|---|---|---|
|
...
Version 2 skrives fra bunden af og i tæt samarbejde med de anvendende interessenter.
Udfases version 1?
Version 1 af API’et vil, på sigt, blive udfaset i den forstand at det ikke længere bliver muligt at tilgå det med KITOS token. Før dette kan ske skal Version 2 dog kunne opfylde de integrationsbehov der findes, og udfasningen vil blive meldt ud i god tid.Ja version 1 er udfaset og ikke længere tilgængeligt med JWT
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
Designbeslutninger
API’et udvikles med afsæt i de logiske grupperinger (moduler/rodaggregater) der eksisterer i KITOS. Data udstilles via et REST API, hvorigennem man i første omgang vil kunne benytte sig af følgende HTTP verber:
...
På de API endpoints hvor der tilbydes listeudtræk skal man forholde sig til paginering via følgende query parametre:
pageSize [1-(100 250| Ubegrænset)]: Antal resultater pr. svar.
Hvis det ikke defineres, vil Swagger dokumentation angive standardværdien. Det fremgår samtidigt her hvorvidt maksimal pageSize er 100 250 eller ubegrænset.
page: [0-Int.MaxValue]: Offset i resultaterne. Offset vil være (pageSize * page)
Hvis det ikke defineres vil KITOS bruge 0 som standardværdi
...
Ønsker man ikke at hente systeminformationen ud har man dog stadig et navn (meningsfuldt for mennesker) såvel som en UUID, der benyttes iftm. senere operationer på API’et.
Særskilte læse- og skrivemodeller (de er ikke kopier af hinanden)
I KITOS API V2 er læse- og skrivemodellerne for den samme ressource ikke éns.
Overordnet set tilstræbes det at felter og datatyper er de samme for både læse og skrivemodeller, men der vil være situationer, hvor de vil adskille sig. Eksempler på de oftest forekommende er:
Krydsreferencer
I skrivemodellerne vil feltet typisk navngives med endelsen “Uuid” og datatypen vil være en UUID (JSON String)
I læsemodellerne vil feltet ikke have endelsen “Uuid” og vil typisk være en kompleks type indeholdende feltet Uuid
og Name
. For krydsreferencer til organisationer, vil der typisk også være et Cvr
felt.
Eksempel - LÆS
Code Block |
---|
{
...
..
"systemContext": {
"uuid": "00000000-0000-0000-0000-000000000000",
"name": "string"
},
"organizationContext": {
"cvr": "string",
"uuid": "00000000-0000-0000-0000-000000000000",
"name": "string"
}
...
..
} |
Eksempel - SKRIV
Code Block |
---|
{
"systemUuid": "00000000-0000-0000-0000-000000000000",
"organizationUuid": "00000000-0000-0000-0000-000000000000",
} |
Beregnede statusfelter
KITOS udstiller i visse tilfælde en samlet status for registreringen (Kontrakt, Systemanvendelse og Databehandlinger), og denne samlede status beregnes på baggrund af registreringerne i andre felter, f.eks. opsigelsesdato på en kontrakt) .Feltet der viser den samlede status vil derfor ikke være synligt på skrivemodellerne men kun på læsemodellerne.
Loginformationer
Informationer der logges af KITOS som f.eks. CreatedBy
og LastModified
udstilles kun på læsemodellerne.
Informationen findes der hvor den registreres (og kan opdateres)
...