Felles studentsystemBakgrunnen for valg av prinsipp
Prinsippene for utforming av FS-API valgt på bakgrunn av mange års erfaring med leveranse av API-er som er skreddersydd for et spesifikt behov eller en gitt klient. Skreddersydde APIer skalerer ikke mhp. kompleksitet og ytelse. Vedlikehold og videreutvikling har blitt vanskelig og (tidvis svært) risikabelt, og det er en stor overlapp mellom tjenestene. Nye behov har gitt nye utvidelser og økt kompleksitet. Noen tjenester eksporterer så mye data at de gir en tilnærmet full kopiering av alle data innen visse forretningsområder. FS-API er ment som svar på dette.
Atomiske mikrotjenester
Det nye FS-APIet vil bestå av atomiske mikrotjenester (også kalt «ressurser») som korresponderer nært med datastrukturen i FS (irrelevante tekniske detaljer i datamodellen abstraheres til en standard representasjon). Utstrakt bruk av filtre, feltutvalg og paginering er ment å gi nødvendig fleksibilitet for å gi klientsiden mulighet til å hente kun de data det er behov for. APIet gir et abstrahert bilde av FS-dataene, der tekniske detaljer til en viss grad skjules for brukeren. Det er derfor ikke en 1:1-sammenheng mellom FS-tabeller og tjenester, da noen tabeller ikke representeres som egen tjeneste, men inkluderes i andre tjenester.
Meldingskø og endringsmeldinger
Vi tilbyr også utsending av endringsmeldinger fra sentrale datatabeller i FS, slik at man ved bruk av meldingskø kan en sanntidsintegrasjon. Dette er «state-of-the-art» for integrasjonstilbydere verden over.
Klientsiden kan selv sette sammen ønskede data
Et slikt API gjør utviklingsjobben på klientsiden større, ettersom utvikler selv må orkestrere de ulike mikrotjenestene og sette sammen data på den måten som dekker det spesifikke behov. Unit er allerede under press for å lage spesialiserte uttrekk på nytt FS-API, men er likevel trygge på at hovedstrategien i de aller fleste tilfeller er den farbare vei, med tanke på hvilke ressurser vi har og den økende etterspørselen etter FS-data.
Et typisk ønske er å få levert innholdet av de data som refereres i svaret på et kall - innbakt i payload (ekspansjon), og da ned til den dybden av nivåer som akkurat denne klienten trenger. Ønsket er forståelig, ettersom det vil gi et datasett levert ferdig ved hjelp av ett eller et fåtall kall, men FS er så komplekst og «alt henger sammen med alt». En referert ressurs referer videre til en annen osv, og over tid med en stor mengde ulike behov fra en voksende mengde klienter, ender vi opp der vi er i våre legacy-tjenester.
Det kan være en mulighet på sikt å legge til en viss kontrollert ekspansjon av referanser, der man eksplisitt velger hvilke referanser det er snakk om (og evt. dybden), men det blir ikke i overskuelig fremtid.