Brukerhistorier ()
Brukerhistorier
BTI001 Som innkjøper av fagsystemer trenger jeg et nettverk for å stille API-krav for tilgang til data slik at jeg kan trekke inn kompetanse til å spesifisere disse og få markedsmakt til å få leverandøren til å implementere dem.
BTI002 Som API-tilbyder som sammenstiller data på vegne av f.eks. kommuner ønsker jeg at de større systemene og registrene skal tilby API-er slik at jeg enkelt kan få tilgang til dataene for å gjennomføre mitt oppdrag.
BTI003 Som innkjøper av fagsystemer ønsker jeg at Statens Standardavtaler inneholder krav til at leverandøren skal tilgjengeliggjøre API-er og data, slik at jeg får tilgang til og slipper å kjøpe tilbake mine egne data.
BTI004 Som API-tilbyder ønsker jeg å tilby informasjon om mine API’er i henhold til en standard for å redusere mine forvaltningskostnader, for eksempel for å få redusert manuelle henvendelser
BTI005 Som API-tilbyder ønsker jeg å tilby informasjon om mine API’er i henhold til en standard for å sikre at det blir enkelt å ta API’ene i bruk slik at vi bidrar til forenkling og samordning
API-tilbyder
BTI006 Som kommunal API-konsument ønsker jeg digital tilgang til kommunesektorens rapporteringskategorier (f.eks. om rapportering er periodisk, om den er hendelsesutløst, eventuell dato for søknadsfrister) slik at jeg kan sikre at alle tidsfrister kan holdes
API-konsument (design time)
BTI007 Som konsument av data fra kommunene ønsker jeg at kommunene tilbyr felles API for den samme informasjonen, uavhengig av hvilket fagsystem/hvilke leverandører de bruker for å forvalte informasjonen, slik at integrasjonen jeg utvikler mot én kommune kan gjenbrukes mot de resterende ca 400 kommunene.
BTI008 Som konsument av data fra offentlige virksomheter ønsker jeg at de offentlige virksomhetene inngår avtaler med sine leverandører som gjør det tydelig hvem som eier dataene, og stiller krav til at de skal være gjøres tilgjengelige uten kostnader, slik at ikke den offentlige virksomheten hindres i å dele sine data med meg som følge av at kostnadene blir for store.
BTI009 Som konsument av offentlig data ønsker jeg en koordinert forvaltning av offentlig master data slik at jeg kan utvikle anvendelser/analyser med forutsigbar kvalitet og fornuftige økonomiske og juridiske betingelser.
API-tilbyder/private grossister
BTI010 Som API-tilbyder ønsker jeg å kunne se om andre tilbyr det samme eller nesten det samme som meg, så at det er mulig å harmonisere mellom “oss” [Livar: Case der det er fleire API-er som tilbyr det samme? Marit: Brreg og Skatt som har same datasett i FDK. Mathias: Felles studentsystem (FS) i UH-sektoren innheld personinformasjon. Kan ikkje konsoliderast med HR-data. Kan ikkje legge ned ein av dei. Dekker relasjonsfeltet i DCAT behovet?]
BTI011 Som API-tilbyder/privat grossist (som er databehandler for innrapportering og tilgjengeliggjøring av informasjon), ønsker jeg at det finnes et forum / nettverk der dataeiere og databrukere utarbeider gode krav til tilgjengeliggjøring og tilbakerapportering av aggregert informasjon.
Eg vil bruke ei bildelingsteneste for å leige ut min bil. Der vil eg gje samtykke til å hente data frå vegvesenet sitt køyretøysregister om kva bilar eg eig, så slepp eg å taste inn informasjonen sjølv, og kan i staden få ferdig utfylt informasjon om kva bil det er, modell etc. Bildelingstenesten kan vidare nytte informasjonen til å hente inn informasjon om mine bilar, til dømes bilde av bilen, så eg slepp å legge inn dette sjølv.
“Den registrerte/subjektet”
MyData, viderebruk av personopplysninger
Som deltakar i ein treningsaksjon, f.eks. Sykletiljobben eller sprekere.no, ønskjer eg å kunne gje treningstenesta tilgang til informasjon om kven som er min arbeidsgjevar, slik at eg kan bli med i ei gruppe for min arbeidsplass og skape intern konkurranse, i staden for at eg må manuelt bli med i grupper, nokon på arbeidsplassen må legge meg til manuelt og bruke mykje tid på ajourhald av dette.
Som brukar er eg villig til å dele mine posisjonsdata slik at ein kan verifisere at eg har tatt buss-reiser og dermed …. kan eg få statistikk om kor mykje eg har reist kollektivt og dette kan brukast til … Premisset for dette er at alle bussar som køyrer kollektivtrafikk har ordentleg GPS-sporing, og at ein har tilgang til historiske posisjonsdata for bussane slik at ein kan kryssjekke kvar og når bussane faktisk har køyrt med mine personlege posisjonsdata.
Som befolkning i et område vil vi gi bevegelsesinformasjon (fra telefon, gpx, google location history osv.) til en kommune for bedre planlegging av a) utbygging av sykkel/turveier b) vedlikehold c) øvrig kommunale tjenester.
Som pasient vil jeg at fastlegen skal ha tilgang til treningsdata (helst AI bearbeidet) (med automatisert varsling om avvik?) for å bidra til bedre, raskere og billigere diagnostisering
Som sykkeleier vil jeg ha automatisert innfylling av tapsmelding til forsikringsselskapet fra innmeldte sak til politiet for å sikre konsistens og spare tid.
Fra BRREGs arbeid: Registrere seg som Über-sjåfør (dokumentere førerkort)
Når Oslo kommune trenger data om hvordan jeg beveger meg -- for å drive byutvikling, prioritere sykkelstier m.m., kan jeg gi dem mine Strava-data
Når jeg flytter til en ny kommune/et nytt sted, vil jeg bli spurt om jeg ønsker å bytte til ny fastlege på mitt nye bosted, med en oversikt over tilgjengelige fastleger med ledig kapasitet.
Når jeg flytter til en ny kommune ønsker jeg at mine data fra gamlekommunen automatisk overføres slik at min nye kommune har oversikt over hvilke behov og tilbud som er relevant for meg.
Jeg ønsker å få tilgang til reisedata (tid, pris, fra-til-sted osv) for ulike transporttjenester slik at jeg kan bruke data i stedet for kvitteringer ved innlevering av reiseregninger.
Jeg lurer på om Osloskolen klarer å få mine barn til å reaching their full potential, og ønsker at en fancy ny utdanningstjeneste skal få tilgang til alle data Osloskolen har om mitt barns oppgaveløsning, f.eks. Hvor lang tid de bruker på ulike typer oppgaver, slik at dataene kan analyseres og jeg kan få et skreddersydd opplegg.
Jeg ønsker å få kontinuerlig økonomisk og rettslig rådgivning fra “velferdsrådgiverne A/S”, slik at de kan identifisere hvilke offentlige tjenester jeg har rett på, evt anbefale meg å jobbe litt mindre slik at jeg kommer under inntektsgrenser som igjen trigger nye utbetalinger -- jobbe mindre og tjene mere!
Som arbeidstager ønsker jeg å få automatisk utfylt reiseregning når jeg sykler, dokumentert med lokasjonsdata fra min mobil
Når jeg kjøper noe i en nettbutikk vil jeg at de nødvendige personalia blir fylt ut automatisk, så lite som mulig, men nok at butikken får sendt produktene til riktig adresse.
API-management
BAM01 - Som ansvarlig for API-management ønsker jeg å publisere mine API i en API-katalog slik at utviklere raskt kan finne frem til mitt API/økt synlighet
BAM02 - Som ansvarlig for API-management ønsker jeg å dokumentere mitt API slik at utviklere raskt kan benytte API-et for tilgang til de data API-et representerer
BAM03 - Som ansvarlig for API-management ønsker jeg å notifisere endringer i mine API til dem som benytter API-ene slik at man ikke bryter kontrakter
BAM04 - Som leverandør av API-management-verktøy ønsker jeg at jeg å kunne tilby automatisk integrasjon med den felles API-katalogen slik at jeg kan selge mer av produktet mitt ved å vise til at det støtter opp under de nasjonale føringene.
BAM05 - Som leverandør av API-management-verktøy ønsker jeg at den felles API-katalogen støtter beste praksis for API-er og de mest utbredte standardene, slik at det blir lett for meg å integrere mitt verktøy med den felles API-katalogen [gjetter jeg på …]
BAM06 - Som ansvarlig for API-management ønsker jeg å kunne fordele eierskap og ansvar for de enkelte API-ene til det forretningsområdet som er dataforvalter/dataeier, slik at de kan være mest mulig selvbetjente og redusere flaskehalser (“publisher portal”)/sikre nærhet og dermed kvalitet (ansvarliggjøring av den rette aktøren)
API-katalogen
Mikrotjenesten/API-et
Felles rammeverk
BAM07 - Som leverandør av API-management-verktøy ønsker jeg å kunne publisere dokumentasjon om API fra mitt API management verktøy til en felles offentlig API katalog
BAM08 - Som ansvarlig for API-management ønsker jeg oversikt over brukerne av mitt API slik at jeg kan formidle endringer i APIet. [Livar: duplikat av BAM03?]
BAM09 - Som ansvarlig for API-management ønsker jeg å kunne administrere nøkler gitt til de enkelte konsumentene slik at jeg enkelt kan fjerne ev. misbruk av API-et
BAM10 - Som ansvarlig for API-management ønsker jeg ???
BAM11 - Som ansvarlig for API-management ønsker jeg å sikre eierskap av API-ene hos forretningseier/dataeier for å sikre kvalitet og eierskap.
BAM12 - Som ansvarlig for API-management ønsker jeg et handlingsrom slik at jeg kan bestille endringer i datamodell/informasjonsmodell når behov/muligheter endrer seg.
BAM13 - Som ansvarlig for API-management ønsker jeg at brukerne av mine API-er skal kunne gi innspill til endringer av mine API-er, slik at jeg gjøre API-ene mine mer brukervennlige.
BAM15 - Som ansvarlig for API-management ønsker jeg å publisere informasjon om kostnader og trafikkbegrensninger for mine API-er, slik at potensielle brukere av mine API-er slipper å spørre meg om denne informasjonen
BAM16 - Som ansvarlig for API-management ønsker jeg tydelige føringer på hvordan mitt API skal dokumenteres og gjøres tilgjengelig i en felles API-katalog slik at arbeidet kan planlegges, fordeles og operasjonaliseres i min virksomhet med et forutsigbart omfang.
BAM17 - Som ansvarlig for API-management ønsker jeg at å tilby effektiv selvregistrering av brukere av API-ene, f.eks. gjennom autentisering via ID-porten/Altinn av dem som tar i bruk API-ene, slik at jeg senker terskelen for å ta API-et i bruk, samtidig som jeg beholder nødvendig oversikt over brukere.
BAM18 - Som ansvarlig for flere datasett og medfølgende API’er ønsker jeg å ha kontroll på de datasettene forretningsenheten min tilbyr og enkelt gi tilgang til datasettene ved behov slik at jeg kan utføre ansvaret jeg har på en enkel måte
API-konsumenter forvaltningen og proffesjonelle
BFP001: Som API-forvalter ønsker jeg at det knyttes opplysninger om sikkerhetsvurderinger tilknyttet felt i API’et (identifiserende, lokaliserende, krav til sikring, osv.) slik at hensyn til innebygd personvern i større grad er ivaretatt for det datasettet som publiseres.
BFP002: Som API-konsument ønsker jeg enhetlig dokumentasjon og mulighet til “kundeservice” fra tjenesteleverandør.
BFP003: Som API-konsument ønsker jeg å kunne se eventuelt tilknyttede informasjonsmodeller der det finnes, slik at jeg også kan finne og kvalitetssikre data og informasjon.
BFP004: Som profesjonell API-konsument ønsker jeg stabile API som beskytter meg mot endringer i underliggende data slik at jeg trenger ikke å oppdatere apiene mine ved dataendringer.
BFP005: Som API-konsument ønsker jeg at dokumentasjonen skal integreres i koden slik at den til enhver tid er oppdatert
BFP006: Som API-konsument ønsker jeg at det ikke er for rigide krav til dokumentering og til selve APIet slik at det ikke hemmer rask utvikling av API
BFP007: Som API-konsument ønsker jeg god og forutsigbar ytelse slik at det er lett å velge bruk av rett API som samsvarer med krav til andre API som inngår i tjenesten/prosessen
BFP008: Som API-konsument ønsker jeg å vite oppdateringsfrekvens slik at jeg kan bestemme egen oppdatering.
BFP009: Som API-konsument ønsker jeg å få dokumentere hvordan en kan oppdatere en egen kopi slik at en til hver tid bruker korrekte data.
BFP011: Som API-konsument ønsker jeg et kontaktpunkt hos API-eier slik at man kan gi tilbakemelding og spørsmål.
BFP010: Som API-konsument ønsker jeg å bare lese endringer som er gjort på siste oppdatering slik at vi slipper å lese hele datasettet.
BFP012: Som API-konsument ønsker jeg varsel på endringer (push-varsel og toveiskommunikasjon) slik at jeg kan forberede tiltak.
BFP013: Som API-konsument ønsker jeg en oversikt over tilgjengelige testmiljø for å teste ut apiene.
BFP014: Som API-konsument ønsker jeg oversikt over tilgjengelige referanseimplementasjoner slik at jeg raskere kan komme i gang med å bruke apiene.
BFP015: Som API-konsument ønsker jeg at nye versjoner av apiene blir gjort tilgjengelig før de settes i produksjon slik at jeg er forberedt.
BFP016: Som API-konsument ønsker jeg en oversikt over hvilke versjoner som er tilgjengelig i hvilke miljø slik at jeg vet hva jeg kan teste mot. (prod og test)
API-beskrivelsen
Referansarkitektur
En konkret tjeneste
Som sluttbruker ønsker jeg å gi samtykke til at en 3dje part kan innhente mine data fra offentlig myndighet slik at jeg slipper å tilgjengeliggjøre dataene selv
Som sluttbruker ønsker jeg å gi samtykke til at en offentlig myndighet kan innhente mine data fra en 3dje part slik at jeg slipper å tilgjengegliggjøre dataene selv.
Som sluttbruker ønsker jeg at en offentlig aktør skal ha tilgang til data om meg hos en annen offentlig aktør
BFP017: Som API-konsument ønsker jeg en endringslogg så tidlig som mulig slik at jeg vet hva som har endret seg mellom versjoner.
BFP018: Som API-konsument ønsker jeg at apiene inneholder referanser til lokale kodeverk som forklarer innholdet i apiene slik at jeg forstår detaljene i apiene.
BFP019: Som API-konsument ønsker jeg at apiene inneholder referanser til begrepene som er brukt i apiene slik at jeg forstår detaljene og bruker dataene korrekt.
BFP020: Som API-konsument ønsker jeg informasjon om oppdateringsfrekvens av dataene eller om dataene er statiske.
BFP021: Som API-konsument ønsker jeg en standardisering av API-grensesnittene (inn og ut) slik at jeg kan ta i bruk nye datasett raskest mulig.
BFP022: Som API-konsument ønsker jeg eksempler/mal på bruk slik at jeg kan ta i bruk nye datasett raskest mulig.
BFP023: Som API-konsument ønsker jeg å se hvilken SLA som er forbundet med API et slik at jeg kan vurdere om det tilfredsstiller mine krav for bruk.
BFP024: Som API-konsument ønsker jeg i de tilfeller hvor API er basert på et lukket datasett å koble meg til et miljø med syntetisk data for bruk i utvikling og test.
BFP025: Som API-konsument ønsker jeg å se hvilke muligheter det finnes for konfigurasjon både hos meg og hos API-leverandør for å begrense tilgjengelig data til mitt faktiske formål. Kommentar: Dataminimering?
BFP026: Som profesjonell API-konsument ønsker jeg forutsigbare økonomiske og juridiske rammer rundt (helst åpen/gratis) tilgang til offentlig data slik at jeg kan lage gode business cases.
BFP027: Som API-konsument ønsker jeg at dokumentasjonen til API-er jeg skal bruke har informasjon om kvalitet og tilgjengelighet, slik at jeg slipper mange henvendelser til API-tilbyder for å få svar på enkle ting.
BFP028: Som API-konsument ønsker jeg at API-et i større grad er “selvbeskrivende” og, dersom det brukes interne koder, at betydningen/forklaringen på disse er enkelt tilgjengelig, slik at jeg forstår hvordan jeg skal bruke API-et.
BFP029: Som API-konsument ønsker jeg at offentlige dataeiere tilbyr APIer så tidlig som mulig (med tilsvarende varsling om datakvalitet) slik at jeg kan utvikle tjenester og bidra til kvalitetsforbedring av dataene.
BFP030: Som API-konsument ønsker jeg å kunne spørre produsent om mer og bedre data slik at vi kan tilby et bedre og mer helhetlig bilde.
BFP031: Som kommersiell API-konsument ønsker jeg at offentlige aktører ikke tilbyr konkurrerende verdiøkende tjenester på de API de tilbyr slik at jeg kan sikre min return on investment.
BFP032: Som API-konsument ønsker jeg klar informasjon rundt lisensen på dataene APIet tilbyr for å raskt se om dette er forenlig med min bruk av dataene.
BFP033: Som API-konsument ønsker jeg at API-et er avledet av en informasjonsmodell og Masterdata, som både sikrer konsistens mellom API og informasjonsmodell og gir mer og bedre dokumentasjon for API-et.
Åpne data statistikk, datajournalistikk og stordata
BB1. Som API-konsument ønsker jeg et spørregrensesnitt (SQL-aktig/SPARQL/ODATA/GraphQL/NoSQL) mot API-et slik at jeg kan utforske datasettet og datasettets struktur/datamodell interaktivt som suplement til å lese dokumentasjon
BB2. Som API-konsument ønsker jeg å gjøre spørringer og sammenstillinger og styre strukturen/formatet på resultatdatasettet selv, slik at jeg kan enkelt kan få det utsnittet av dataene som passer til den oppgaven jeg skal løse.
BB3. Som API-konsument ønsker jeg å gjøre spørringer som gir meg dataene jeg har rettighet til å få (og ikke blir blokkert tilgang fordi API-et bare gir tilgang til mer data enn jeg har rettigheter til), slik at jeg kan få tilgang til data [rettigheter]
BB4. Som API-konsument (ETL) ønsker jeg API-er som gir meg uttrekk som er tilpasset mine rettigheter og filtreringsbehov slik at jeg kan innhente uttrekket jeg trenger og har rett til. [rettigheter]
BB5. Som API-konsument ønsker jeg å få tilgang til eksempler på bruk av API-et slik at jeg kan se mulighetene for bruk og bedre forstå hva API-et er ment å brukes til. [dokumentasjon]
BB6. Som API-konsument ønsker jeg at semantikken rundt dataene er forklart (dataene er definert), slik at jeg kan ta et informert valg om å bruke dataene fordi jeg forstår kontekst, formål og omfanget av dem. [dokumentasjon]
BB7. Som API-konsument ønsker jeg at det angis tydelig i dokumentasjonen hvilke data som er tilgjengelig, men også hva som ikke er tilgjengelig, slik at jeg slipper merarbeid pga. uklar dokumentasjon. [dokumentasjon]
BB8. Som API-konsument ønsker jeg at utforskingsfasen/exploration/discovery gir meg rask oversikt og innsikt slik at jeg minimerer tiden jeg bruker på å velge et utsnitt eller må bruke egne verktøy for å skaffe meg oversikt. [dokumentasjon]
BB9. Som API-konsument (datajournalist) ønsker jeg å få forklaringer/dokumentasjon på hvordan dataene henger sammen slik at jeg kan spare tid på semantisk fortolkning (kobling mot datakatalogen?) [dokumentasjon]
BB10. Som API-konsument ønsker jeg mulighet til å innhente data om tekstdatasett slik at jeg kan lage analyser av disse og koble til andre kilde. [tekst som data]
BB11. Som API-konsument (analytiker) ønsker jeg mulighet for å legg inn spørsmål, tips, eksempler knyttet til APIer slik at jeg kan øke min egen, andre brukere og api-forvalternes kjennskap om semantikk, selve APIen og bruk [økosystem]
BB12. Som API-konsument ønsker jeg at API-ene støtter de “connector”-teknologiene som brukes av mine foretrukne verktøy for sammenstilling, analyse og visualisering, f.eks. Tableau, slik at jeg slipper å lage en mellomløsning/laste ned datasett for å analysere dem [samhandlingsevne]
BB13. Som API-konsument ønsker jeg at de tjenestene offentlig sektor har utviklet på sine egne API gjøres tilgjengelig som åpen kildekode, slik at jeg kan gjenbruke relevante deler av koden for mitt eget konsum av API-et. [gjenbruk av kildekode]
BB14. Som API-konsument ønsker jeg standardavtaler for både vilkår for bruk av data og tjeneste slik at jeg vet hvilke vilkår og tjenestenivå jeg har å forholde meg til. [databehandleravtaler, SLA]
BB15. Som API-konsument ønsker jeg at relevante opplysninger som ikke er tilgjengelig i API-et er omtalt i dokumentasjonen, slik at jeg kan bruke API-et riktig. [dokumentasjon]
BB16. Som API-konsument ønsker jeg at støttedatasett (f.eks. kodelister) er omtalt i dokumentasjonen slik at jeg kan anvende data fullt ut.[dokumentasjon]
BB17. Som API-konsument ønsker jeg at spørringer, programkode og bibliotek som andre utvikler gjøres tilgjengelig som åpen kildekode slik at jeg kan dra nytte av disse i min prosess [gjenbruk av kildekode]
BB18. Som API-konsument ønsker jeg at kildekoden til API-tjenesten er tilgjengelig som åpen kildekode, slik at jeg kan lese kildekode for å forstå APIet og kunne bruke det optimalt [dokumentasjon]
BB19. Som API-konsument ønsker jeg å diskutere semantiske og tekniske spørsmål i en åpen kanal (wiki, github issues el liknende) for APIet jeg bruker, slik at brukerne kan hjelpe hverandre og tilbyder kan kommunisere åpent med sitt økosystem. [nettverk, dokumentasjon]
BB20. Som API-konsument ønsker jeg eksempel på bruk av dataene som en del av dokumentasjonen av API-et, slik at de er enklere å fortså og ta i bruk [dokumentasjon]
BB21. Som API-konsument ønsker jeg å kunne laste ned endringer i et datasett jeg allerede har en lokal kopi av slik at jeg effektivt kan vaske eget register basert på samme datakilde. [varsel]
BB22. Som API-konsument ønsker jeg å få dokumentasjonen fra samme sted som jeg henter ut data, slik at jeg vet at det er oppdatert og lett tilgjengelig. [dokumentasjon]
BB23. Som API-konsument (stordata) ønsker jeg tilgang til tekster i maskinlesbart format og under en åpen lisens slik at jeg fritt kan bruke tekster i maskinanalyse av språk eller lignende.[tekst som data]
BB24. Som API-konsument (ETL) ønsker, jeg stabile API-er som er uavhengige av underliggende data slik at jeg ikke trenger å følge med endringer i data formater/strukturer. [forutsigbarhet]
BB25. Som API-konsument (ETL) ønsker jeg mulighet til å abonnere på endringsvarslinger om både data og API-versjoner slik at jeg kan oppfriske data og/eller utnytte nye datafelter. [varsel]
BB26. Som API-konsument ønsker jeg at API-ene jeg har tilgang til er de samme som API-forvalteren selv benytter til sin tjenesteutvikling, slik at jeg kan ha tillit til at forvaltning og videreutviklingen av API-ene gis prioritet og er verdt å bruke tid på å lære, gjøre bruk av [tjenestenivå/sla]
BB27. Som API-konsument ønsker jeg å kunne laste ned en komplett versjon av datasettet i tillegg til API-funksjonalitet slik at jeg kan kjøre analyse på en lokal kopi av datasettet der dette er mest hensiktsmessig.[nedlasting]
BB28. Som API-konsument ønsker jeg at API-et har god ytelse slik at jeg kan gjøre enkeltoppslag og ikke blir tvunget til å laste ned hele datasettet fordi API-et har lav ytelse. [tjenestenivå]
BB29. Som API-konsument ønsker jeg en god mekanisme for å få beskjed om endringer i API eller dataformat (f.eks. ikke-brytende-endring som nye felt i dataformatet) slik at jeg kan tilpasse konsum av data når dataformatet blir endret eller utvidet.[varsel]
BB30. Som API-konsument ønsker jeg å slippe å ha en kopi av xxregistreret eller datasettet slik at jeg kan være sikker på at dataene er oppdaterte. [tjenestenivå]
BB31. Som API-konsument ønsker jeg at datasett som er gjort tilgjengelig for nedlasting har et forutsigbart URL-regime for siste versjon og historiske data slik at nedlasting kan automatiseres. [nedlasting, forutsigbarhet]
BB32. Som API-konsument (datajournalist) ønsker jeg at strukturen i datasettene er stabile, slik at jeg ikke trenger gjøre endringer i min integrasjon/kode når nye versjoner hentes. [forutsigbarhet]
BB33. Som API-konsument ønsker jeg å kunne laste ned kun endringer i et datasett for å oppdatere min lokale kopi av et datasett slik at jeg slipper å laste ned hele datasettet på nytt og import-jobben blir mindre. [varsel]
BB34. Som API-konsument ønsker jeg å kunne se når hvilke deler av et datasett som er endret slik at jeg kan analysere endringer i data. [varsel]
BB35. Som API-konsument ønsker jeg å kunne abonnere på hendelser slik at jeg får beskjed når hendelser oppstår. [varsel]
BB36. Som API-konsument (ETL) ønsker jeg å unngå å laste komplette datasett og heller få de delene som har endret seg siden sist jeg lastet ned datasett slik at jeg minimerer egen ressursbruk. [varsel]
Studenter, gründere og app-utviklere
BA1. Som API-konsument (student) ønsker jeg å filtrere på dataformater i oversikter over (åpne) API-er slik at jeg kan finne API-er i det formatet jeg ønsker å lære mer om eller filtrere ut de jeg ikke kan noe om.
BA2. Som API-konsument ønsker jeg umiddelbar tilgang (slipper å vente på manuell tildeling av API-nøkler og tokens) til data (eller testdata) slik at jeg kan vurdere og eventuelt ta i bruk API-et umiddelbart.
BA3. Som API-konsument ønsker jeg at det pekes til gode landingssider for API-et slik at jeg raskt settes i stand til å ta det i bruk.
BA4. Som API-konsument ønsker jeg eksempler på API-requests slik at jeg kan komme fort i gang.
BA5. Som API-konsument ønsker jeg at alle begreper linker direkte til en forklaring av begrepet slik at jeg slipper å lete gjennom dokumentasjonen. [kommentar: forskjell på begrep i den tekniske dokumentasjonen (f.eks. parameter i forespørsel) vs. begrep i datasettet (f.eks. fagtermer)]
BA7. Som API-konsument ønsker jeg selvforklarende API-er slik at jeg kan komme raskt i gang, få raskt nytte av API-et.
BA8. Som API-konsument ønsker jeg mulighet til enkelt å teste API-ene (utforske) f.eks. gjennom Swagger eller tilsvarende, slik at jeg raskere forstår API-et, og raskere klarer å bruke det (riktig) [ref BA7].
BA9. Som API-konsument ønsker jeg at API-et er tilrettelagt for bruk, og ikke bare speiler innholdet i en database, slik at jeg kan slippe å forholde meg til et fagdomene, sette meg inn i interne kodeverk [brukerorientert, ikke avsenderstyrt …]
BA10.Som API-konsument ønsker jeg en indikasjon på hvor dynamisk datasettet er, slik at jeg har en idé om hvor ofte jeg trenger å lese data på nytt.
BA11. Som API-konsument ønsker jeg at jeg kan bytte til nye versjoner av API-et når det passer meg [Kommentar frå Livar: Litt usikker på denne. Her er det kanskje snakk om versjonering av API, at ein sjølv kan velje når tid ein byttar til ny versjon av API? I motsetnad til at eit API ikkje er versjonert og ved "breaking-changes" så må ein forholde seg til når API-et gjer eit brått hopp til ny versjon?]
BA12. Som API-konsument ønsker jeg å hente inn data uavhengig av dataenes egentlig form slik at den ikke endrer seg når dataformatet endres.
BA13. Som API-konsument ønsker jeg at Tableau/R/etc kan hente inn data for meg slik at jeg kan lage visualiseringer uten å måtte vite noe om API-er.
BA14. Som API-konsument ønsker jeg lenker til applikasjoner som bruker datasettet, slik at jeg kan finne gode eksempler på bruk av API-et og datasettet. [kommentar: også programvarebibliotek og anna kodeverk som er relevant
BA15. Som API-konsument ønsker jeg at alt jeg er avhengig av for applikasjonen min er tilgjengelig fra samme server, inklusive kodeverk, slik at CORS opprettholdes.
BA16. Som API-konsument ønsker jeg at API-et tåler stor trafikk slik at jeg kan bruke API-et direkte i applikasjon
BA17. Som API-konsument ønsker jeg beskrivelse av API-et sin kapasitet slik at jeg vet om jeg trenger en egen server for sluttbrukerapplikasjoner ved svært høy trafikk.
BA18. Som API-konsument ønsker jeg lenker til aktuelle kodeverk (f.eks. kommunenummer, næringskoder) slik at jeg lett kan hente støtte-datasett og dermed benytte datasettet fullt ut.
BA19. Som API-konsument ønsker jeg API der kodeverk (f.eks. kommunenummer, næringskoder) er en del av API-responsen slik at jeg slipper å utføre flere API-kall og hente fra ulike kilder for å få data jeg trenger.
BA20. Som API-konsument ønsker jeg informasjon om hvor jeg kan finne statiske data som brukes til API-requests (Kommunenr, Kommunenavn..) slik at jeg slipper å lete etter dette selv.
BA21. Som API-konsument ønsker jeg et API som gir godt strukturerte responser slik at data er lett å bruke.
BA22. Som API-konsument (app-utvikler) ønsker jeg en landingsside hvor jeg kan stille spørsmål om bruk av API-et slik at jeg kan bruke det mest mulig hensiktsmessig, og gjerne med henvisninger til kjent brukt av API-et.
BA23. Som API-konsument (app-utvikler) ønsker jeg en landingsside hvor jeg får tilgang til FAQ om API-et. [Kommentar: manglar “slik at <forretningsverdi>”]
BA24. Som API-konsument ønsker jeg, når jeg får en respons fra et datasett, en henvisning til arkiverte versjoner av “det samme” datasettet (med elementer som ikke lenger finnes i det løpende datasettet), slik at jeg kan gi en mer komplett respons til brukeren.
BA25. Som API-konsument ønsker jeg at beskrivelser av API-er som ikke lengre er tilgjengelige, skal fjernes fra API-katalogen, slik at jeg slipper å lese om API-er som jeg uansett ikke kan bruke.
BA26. Som API-konsument ønsker jeg at API-et støtter CORS slik at jeg kan nå det fra en webapplikasjon uten å måtte gå via egen backend eller proxy.
BA27. Som API-konsument ønsker jeg at API-forvaltere lærer av webutviklere og tenker på brukerinvolvering og brukertesting slik at jeg kan få et API-som er lagt til rette for bruk
BA28. Som API-konsument ønsker jeg informasjon om ytelsesmessige (svartid, antall oppslag) begrensninger i API-et, slik at jeg kan vurdere om API-et har god nok ytelse til mitt formål.
BA29. Som API-konsument ønsker jeg informasjon om hvordan jeg kan skaffe meg tilgang til API-er som ikke er offentlig tilgjengelig. [Kommentar: manglar “slik at <forretningsverdi>”]
BA30. Som API-konsument ønsker jeg informasjon om hvilke hjemler som gir tilgang til API-er der tilgangen er begrenset, slik at jeg kan vurdere om min virksomhet har lov til å benytte API-et til det aktuelle formålet.
BA31. Som API-konsument ønsker jeg informasjon om eventuelle økonomiske betingelser for bruk av API-er, slik at jeg kan vurdere hvorvidt det er aktuelt å betale for bruk av API-et.
BA32. Som API-konsument (gründer) ønsker jeg en tematisk oversikt over offentlige API slik at jeg kan lage nye tjenester.
BA33. Som API-konsument ønsker jeg at det er så få tekniske sperrer på API-ene som mulig slik at jeg kan ta det i bruk med minst mulig “prosess” mot API-forvalteren
BA34. Som API-konsument ønsker jeg at eventuelle krav til API-nøkler etc lar seg løse raskt/selvbetjent slik at jeg kan komme i gang raskt. [f.eks. autorisering basert på eksisterende mekanismer fremfor å måtte kontakte forvalter og vente på svar (ID-porten, Altinn), bruksvilkår fremfor avtaler]
BA35. Som API-konsument ønsker jeg at det er tydelig hva som er de rettslige rammene for bruk av API-ene slik at jeg kan være sikker på at jeg ikke kan få krav mot meg senere, f.eks. NLOD.
BA36. Som API-konsument ønsker jeg at noen tar jobben med å holde oversikt over om API-er er tilgjengelige, utilgjengelige, stabilt, deprecated etc slik at jeg slipper å begynne å ta det i bruk først før jeg oppdager det.
BA37. Som API-konsument ønsker jeg at tilgjengelige API-er er robuste slik at jeg kan anta at integrasjonen fungerer også ved høy trafikk
BA38. Som API-konsument ønsker jeg (kanskje ....) HATEOAS og linked data-baserte API (for eks. JSON-LD/RDF-representasjoner) slik at jeg kan se hvilke opsjoner jeg har basert på de responsene jeg allerede har fått (den tilstanden jeg er i). [Kommentar frå Steinar: “basert på én informant ... han var tydelig på at han hadde gode erfaringer med API-er med RDF-data”]
BA39. Som API-konsument ønsker jeg at begreper i API-ene er dokumentert slik at jeg forstår dokumentasjonen og bruker dataene i API-ene rett.
BA40. Som API-tilbyder* ønsker jeg retningslinjer og beste praksis for dokumentasjon av API-ene mine slik at jeg kan dokumentere så effektivt og bra som mulig.
BA41. Som API-konsument som benytter verktøy for å generere deler av kildekoden ønsker jeg at API-et er dokumentert iht “Open API Specification”, slik at jeg kan bruke kodegenereringsverktøy for å generere mye av den kildekoden som trengs for å bruke API-et fremfor å måtte skrive den selv [ref epost]
BA42. Som API-konsument ønsker jeg varsler om “breaking changes” slik at jeg kan gjøre de nødvendige endringene før de brekker mine systemer/applikasjoner også. [f.eks. ved registrere e-postadresse]
BA43. Som API-konsument ønsker jeg å bli varslet om at et API er “deprecated” (skal tas ut av bruk), slik at jeg kan oppdatere min applikasjon.
BA44. Som API-konsument ønsker jeg intelligente API-er som kan f.eks. filtrere, aggrerere, gruppere slik at jeg bare få inn de resultater jeg trenger av hensyn til personvern, kapasitet etc.
BA45. Som API-konsument ønsker jeg et API med gode muligheter for å filtrere data slik at jeg kan hente ut akkurat det utsnittet av datasettet som jeg trenger til mitt formål og slipper å gjøre ekstra prosessering av responsen jeg får fra API-et.
BA46. Som API-konsument ønsker jeg mulighet for å bruke filtre i API-et slik at jeg kan ha bedre kontroll med hvilket utvalg av data jeg mottar, og ikke er avhengig av hvilke utvalg API-forvalteren har definert.
BA48. Som API-konsument ønsker jeg at API-ene jeg bruker tilbyr komplett nedlasting av datasett slik at jeg kan bearbeide data lokalt.
BA49. Som API-konsument ønsker jeg ikke å tvinges til å bruke API-er der hvor det aller enkleste for meg ville vært å få lastet ned hele datasettet. [kommentar: ønskjer i alle fall anledning til å velje]
BA50. Som API-konsument, ønsker jeg å kunne gi tilbakemeldinger til god (eller dårlig) “beste praksis” for API-er, slik at dette kan være til hjelp for framtidige API-er som utvikles.
BA51. Som API-konsument ønsker jeg mulighet til å gi tilbakemeldinger slik at jeg kan melde fra om feil eller foreslå forbedringer
BA52. Som API-konsument ønsker jeg en enkel måte å rapportere inn feil i datakatalog (f.eks. Lenker som ikke fungerer) slik at jeg slipper å bla i utdatert innhold.
BA6. Som API-konsument ønsker jeg å kunne på en enkel måte gi kontekstavhengige tilbakemeldinger til API-forvalteren, slik at dokumentasjonen og eller API-et blir bedre.
BA47. Som API-konsument ønsker jeg at API-ene jeg skal bruke er så like som mulig (men så forskjellige som nødvendig), slik at jeg ikke trenger sette meg inn i unødvendig mye nytt for hvert API jeg skal vurdere eller bruke.
BA53. Som API-konsument ønsker jeg at API-et støtter HTTP-standard med accept header for å velge data-format slik at kan gjøre det jeg er vant til.
BA54. Som API-konsument ønsker jeg REST-API-er i tråd med REST-prinsippene/beste praksis slik at jeg kan bygge på erfaringene mine med andre REST-API-er, og forstå effekten av kallene i API-et med minst mulig teknisk dokumentasjon.
BA55. Som API-konsument, ønsker jeg at API-et er designet etter en felles “beste praksis” som gjelder for API-er i API-katalogen, slik at jeg lett kjenner meg igjen på tvers av API-ene i katalogen.
API-forvalter og API katalogeier
1.Som API-forvalter ønsker jeg at katalogen dekker informasjonsbehovet til de som skal benytte API-ene jeg forvalter, slik at jeg slipper å besvare henvendelser fra dem/redusere antall henvendelser [frigjøre ressurser]
2. Som API-forvalter ønsker jeg at katalogen gir føringer for hvordan API-ene mine skal dokumenteres, etter “beste praksis”, så jeg slipper å sette meg inn i/holde meg oppdatert på hva som er beste praksis for API-dokumentasjon [frigjøre ressurser/bedre kvalitet]
3. Som API-forvalter ønsker jeg at katalogen og dens underliggende spesifikasjoner og standarder gir krav jeg kan bruke i avtaler med leverandører/anskaffelser slik at jeg slipper å sette meg inn i hvilke krav jeg bør stille.
4. Som API-forvalter ønsker jeg råd og forslag til avtaler med konsumenter slik at jeg kan gjøre flere API-er tilgjengelige for eksterne (f.eks. innovatører) og er trygg på å ha et godt avtaleverk og slipper å gjøre grunnarbeidet med vilkår og avtale for bruk.
5. Som API-forvalter ønsker jeg at API-katalogen kan vise min Swagger-dokumentasjon slik at jeg bare kan eksponere for eksempel Swagger-data (YAML) og slipper å drifte min egen Swagger UI-nettside. [relatert til Swagger-brukerhistorien, trur eg]
6. Som API-forvalter ønsker jeg at de aktivitetene jeg må gjøre og de standardene jeg må forholde meg til for å gjøre API-dokumentasjonen tilgjengelig i en nasjonal API-katalog, også gir verdi for andre, kommersielle, internasjonale API-kataloger, f.eks. synliggjøring på søkemotorer, ref Schema.orgs arbeid med vokabular for WebAPI http://pending.webschemas.org/WebAPI
7. Som API-forvalter har jeg behov for å selv velge hvor selve dokumentasjonen skal ligge, slik at jeg kan bruke de verktøyene som er mest hensiktsmessig til formålet.
8. Som API-forvalter som tilbyr data som ikke er åpne ønsker jeg å synliggjøre testmiljø for mine API-er slik at de er lette å oppdage for brukerne
9. Som API-forvalter ønsker jeg en felles løsning for API-dokumentasjon som er så god at jeg selv ønsker å bruke løsningen fremfor andre verktøy
10. Som en API-forvalter ønsker jeg å kunne ha “FAQ-funksjonalitet” (eller kunnskapsbase), slik at brukerne mine lettere kan få tak i svar på kjente utfordringer og jeg kan redusere kostnader ved å håndtere brukerhenvendelser.
11. Som API-forvalter/eier ønsker jeg å generere dokumentasjon ut fra koden eller tester, slik at jeg er sikker på at dokumentasjonen til enhver tid er oppdatert.
12. Som APi-forvalter/eier ønsker jeg at standarder og beskrivelser er helt maskinlesbare slik at høsting og bruk kan automatiseres og min rolle automatiseres bort eller erstattes av AI.
13. Som API-forvalter ønsker jeg å kunne påvirke utformingen av felles nasjonale oppskrifter for API-beskrivelser slik at de dekker mine behov.
14. Som API-forvalter/eier ønsker jeg en ensartet og samlet API-katalog slik at det blir enklere å publisere informasjonen.
15. Som API-forvalter/eier ønsker jeg en ensartet og samlet beskrivelse av alle våre API-er slik at det er enkelt for brukerne å gjenbruke sin kunnskap om de skal bruke flere API-er.
16. Som API-forvalter ønsker jeg å vite av hvem og hvor ofte mine API-er brukes (trafikkdata og bruksmønstre), slik at jeg optimere tilgang til API-er og ta stilling til hvilke API-er som eventuelt skal avvikles, samt kunne få grunnlag for å kunne rapportere på gevinstrealisering.
17. Som API-forvalter ønsker jeg å vise frem eksempel på bruk av mine API-er slik at verdien av API-ene blir synliggjort og det kan inspirere flere til å bruke API-ene og hvordan bruke API-ene.
18. Som API-forvalter ønsker jeg oversikt over integrasjoner mot mine API-er slik at konsekvenser og kostnader ved endringer kan forutses og minimeres.
19. Som API-forvalter ønsker jeg kontaktinfo til de som bruker mine API slik at jeg kan ta kontakt med de om brukerundersøkelser, driftsmeldinger, endring av API, nye API og liknande. [dersom jeg ikke har egne løsninger for dette allerede]
20. Som API-forvalter ønsker jeg at brukerne av mitt API skal ha en åpen kommunikasjon med meg og hverandre om hvilke behov de har som ikke er dekket i dag, slik at min videreutvikling treffer flest mulig brukere på en tilstrekkelig måte.
21. Som API-forvalter ønsker jeg å få en effektiv kanal for å få tilbakemeldinger og behov fra de som bruker API-ene mine, slik at det blir lettere å prioritere riktig ved videreutvikling av API-ene [styrke dialog med brukerne av API-ene]
22. Som en API-forvalter med allerede eksisterende API-katalog, ønsker jeg at løsningen er fleksibel(?)/legger til rette for automatisk høsting, slik at jeg kan vedlikeholde dokumentasjonen min lokalt.
23. Som API-forvalter ønsker jeg at de API-ene jeg tilbyr skal være lette å finne og ta i bruk for de som har verdi av dem, slik at innsatsen jeg har lagt ned i API-ene får størst mulig verdi [forsvare kostnadene ved utviklingen/forvaltningen av API-ene/generere størst mulig nytte]
24. Som API-forvalter (f.eks. av hotell.difi.no) ønsker jeg at API-ene er lette å finne og ta i bruk slik at verdien blir realisert.
25. Som API-forvalter som forvalter API-er til autoritative data ønsker jeg at API-katalogen skal prioritere presentasjon av mine API-er fremfor API-er som tilbyr samme data, men fra ikke-autoritative kilder, slik at API-brukerne ikke ubevisst bruker ikke-autoritative data
26. Som API-forvalter ønsker jeg at opplysninger som er relevante for datakatalogen og som finnes i API-et (feks “sist oppdatert”), høstes til datakatalogen slik at datasettbeskrivelsen er så god som mulig.
27. Som API-katalogeier ønsker jeg å koordinere beskrivelsene av API-ene som inngår i min katalog, slik at beskrivelsene fremstår som ensartet for de som skal benytte API-ene.
28. Som API-katalogeier ønsker jeg å, slik at jeg kan ha en total oversikt over API-ene våre kunne vite hvilke API-er min virksomhet tilbyr (og forvalte de på felles måte, vite hvem som bruker hvilke API-er osv.).
29. Som API-katalogeier med en eksisterende API-dokumentasjon ønsker jeg å bruke eksisterende API-dokumentasjon slik at jeg slipper å vedlikeholde API-dokumentasjon (manuelt) flere steder.
30. Som API-portaleier ønsker jeg at alle skal tilby sin informasjon på samme format, OG at alle har et eget API som beskriver sin katalog eller sitt API, slik at portalen enklest mulig kan høste og sammenstille informasjon om API-er.
31. Som API-portaleier ønsker jeg å få inn statistikk fra API-forvaltere slik at vi kan få et overordnet oversikt for hele sektoren/landet.
32. Som API-bruker ønsker jeg å registrere en anvendelse slik at jeg kan oppgi den i API-kallet. Alternativt: Som API-forvalter ønsker jeg at brukere kan registrere seg med en ID som de bruker i API-kallet slik at jeg kan koble trafikk og anvendelse. [f.eks. ved overbruk av API-et kan man lett kontakte den som har satt opp anvendelsen]
33. Som API-forvalter ønsker jeg at man tilbyr ei løsning/det blir spesifisert hvordan man skal tilby API på samme format.
34. Som API-katalogeier som ikke har en katalog, så ønsker jeg enkel måte å eksponere API-er på, ikke egen katalog med maskinlesbar beskrivelse, slik at jeg slipper å lage et eget verktøy med egne beskrivelser.
35. Som API-katalogeier ønsker jeg å kategorisere API-innslagene, slik at det kan differensieres mellom de.
FDK
BFDK01 - Som forretningsutvikler ønsker jeg å se hvilke datasett som tilbyr API, slik at jeg kan vurdere om det kan brukes i mine tjenester.
BFDK02 - Som forretningsutvikler ønsker jeg å søke etter API, slik at jeg raskt kan finne ut om det finnes data jeg kan gjenbruke
BFDK03 - Som forretningsutvikler ønsker jeg å se detaljerte beskrivelser av APIene, slik at jeg kan vurdere om de er av tilstrekkelig kvalitet for bruk i mine tjenester
BFDK04 - Som forretningsutvikler ønsker jeg å filtrere på datasett som har API, slik at jeg bedre treff på mine søk i katalogen.
BFDK05 - Som forretningsutvikler ønsker jeg å kunne sammenligne APIere, slik at jeg vurdere om et API passer bedre enn et annet for min bruk.
BFDK06 - Som arkitekt ønsker jeg å se hvilke data jeg må benytte for å gjøre oppslag mot et API og hvilke data jeg får tilbake slik at jeg kan planlegge design av løsning.
BFDK07 - Som datasetteier (og som beskriver datasett i datakatalogen) ønsker jeg å kunne kople beskrivelser av APIer (i flertall) til et gitt datasett, slik at jeg kan vise hvilke distribusjoner som finnes av et datasett
BFDK08 - Som datasetteier (som beskriver datasett i datakatalogen) ønsker jeg å kunne plukke fra API-beskrivelsen dataelementene som jeg ønsker å ta med i datasettbeskrivelsen, slik at dataelementene jeg tar med gjenspeiler det som APIet virkelig kan tilby.
BFDK09 - Som datasetteier for historiske (avleverte) data ønsker jeg å kunne koble de historiske datasettene med tilsvarende aktive/nåværende datasett, slik at jeg kan tilby brukerne en helhetlig tilgang til dataene.
BFDK10 - Som konsument ønsker jeg å få en liste over de datasett jeg vil ha tilgang til, presentert med grunnleggende informasjon om API slik at jeg sammenligne egenskaper (for eksempel hvilken protokoll som er brukt) ved API-ene
BFDK11 - Som konsument ønsker jeg å abonnere på varslinger om etablering, endring, driftsstans og avvikling av API’er slik at jeg kan tilpasse meg endringer
BFDK12 - Som konsument ønsker jeg kontaktinformasjon til brukerstøtte for API slik at jeg kan få hjelp
BFDK13 - Som konsument av et åpent api ønsker jeg informasjon om hvor pålitelig leveransen av data er (forventet oppetid, responstid ved feil osb) slik at jeg kan gjøre en tilstrekkelig ROS-analyser for min integrasjon
Som sluttbruker ønsker jeg at en privat virksomhet skal ha tilgang til data om meg fra en tredjepart (app) slik at jeg kan slippe å tiljgengeliggjøre dataene selv
API-mangement verktøyleverandør
Dataeier
Forretningsutvikler
Altinn
Som utvikler i Altinn ønsker jeg å kunne registrere tredjepart API uten at API-eier har kjennskap til dette slik <hensikt>
Som utvikler i Altinn ønsker jeg å kunne registrere de API jeg utvikler for mine T.3 applikasjoner slik at <hensikt>
Som API-eier ønsker jeg å kunne beskrive funksjonaliteten i API-et på en overordnet måte slik at brukere får et innblikk i hva API-et innholder.
Informasjonsforvaltning fagmiljø
Som API-eier ønsker jeg å kunne beskrive et API som ikke nødvendigvis kan knyttes til et datasett, slik at også dynamiske tjenester kan synliggjøres for andre konsumenter.
Som API-eier ønsker jeg å angi at API’et skal være tilgjengelig i en runtime-tjenestekatalog (SMP/capability lookup) og Altinn tjenestekatalog/Authorization for samtykke og tilgangsstyring.
Som API-konsument ønsker jeg å vite hvilken interaksjonsform som tilbys i APIet (spørring, feed, fil) , slik at jeg kan vite om det dekker mine behov.
Som API-katalogeier ønsker jeg å kategorisere API-innslagene, slik at det kan differensieres mellom de.
Som ansvarlig for API-Management ønsker jeg en enkel måte å varsle endringer i oppetid
Som API-forvalter ønsker jeg en enkel måte å varsle endringer spesifikasjon av tjenester
Skatteetaten
Som API-forvalter/API-Management ansvarlig ønsker jeg en enkel måte å kommunisere informasjon rettet til enkeltbrukere av tjenester
Som API-forvalter/API-Management ansvarlig ønsker jeg en enkel måte å kommunisere sensitiv informasjon sikkert til (enkelt)brukere av tjenester
Som API-forvalter/ansvarlig for API-management ønsker jeg en enkel måte å kommunisere livssyklus planer og garantier for en tjeneste (f.eks. nedleggelse/utfasing) slik at jeg kan avvikle tjenester når det er ønskelig
Som potensiell API-konsument ønsker jeg å kjenne til livssyklus planer og garantier for en tjeneste (f.eks. nedleggelse/utfasing) slik at jeg ikke gjør meg avhengig av eksterne APIer som kan forsvinne
Som API-konsument ønsker jeg standardiserte autentiserings- og autoriseringsmekanismer som kan gjenbrukes for flere tjenester
Som API-konsument ønsker jeg single sign on (SSO) mellom flere tjenester jeg benytter slik at jeg unngår separat autentisering mot hver enkelt tjeneste
Som API-konsument ønsker jeg at nasjonal/delt infrastruktur tilbyr felles mønstre for autentisering og autorisering mot API slik at jeg slipper å bestille og forvalte tilgangsstyring hos hver enkelt tjenestetilbyder.
Som API-forvalter/API-management ansvarlig ønsker jeg en nasjonal/delt infrastruktur for administrasjon og utstedelse av tilgangstokens for API-konsumenter slik at jeg slipper å utstede og forvalte disse selv (dette gjelder både hjemmelsbasert og samtykkebasert tilgang).
Som API-forvalter ønsker jeg at definerte APIer i API-katalogen kan overføres til felleskomponenter for tilgangsstyring og autentisering slik at jeg slipper å registrere disse dobbelt (og dermed risikere feil i registreringer)
Som API-konsument ønsker jeg å kunne gi strukturerte tilbakemeldinger (f.eks. feil) og endringsforslag for tjenester slik at tjenestene kan forbedres
Som API-forvalter ønsker jeg å kunne motta strukturerte tilbakemeldinger (f.eks. feil) og endringsforslag for mine tjenester slik at tjenestene kan forbedres
Som API-forvalter ønsker jeg å kunne få overført mine API-definisjoner til en runtime tjenestekatalog (SMP, CapabiliityLookup eller den tekniske endepunktedelen av KoFuVi?) for å kunne legge til metadata for runtime-kall slik at jeg ikke må registrere mine API-definisjoner dobbelt.
Det er behov for enkel tilgang til data av god kvalitet, og som er beskrevet på en standardisert måte
Difi konseptutredning "deling av data"
Datakonsumenter har behov for tilgang til dataene på en enkel og standardisert måte.
Datakonsumenter har behov for et ryddig avtaleregime for tilgang til dataene.
BTI001 Som innkjøper av fagsystemer trenger jeg et nettverk for å stille API-krav for tilgang til data slik at jeg kan trekke inn kompetanse til å spesifisere disse og få markedsmakt til å få leverandøren til å implementere dem. API-tilbyder/private grossister
BTI003 Som innkjøper av fagsystemer ønsker jeg at Statens Standardavtaler inneholder krav til at leverandøren skal tilgjengeliggjøre API-er og data, slik at jeg får tilgang til og slipper å kjøpe tilbake mine egne data. API-tilbyder/private grossister
API-tilbyder BTI002 Som API-tilbyder som sammenstiller data på vegne av f.eks. kommuner ønsker jeg at de større systemene og registrene skal tilby API-er slik at jeg enkelt kan få tilgang til dataene for å gjennomføre mitt oppdrag.
API-tilbyder BTI004 Som API-tilbyder ønsker jeg å tilby informasjon om mine API’er i henhold til en standard for å redusere mine forvaltningskostnader, for eksempel for å få redusert manuelle henvendelser
API-tilbyder BTI005 Som API-tilbyder ønsker jeg å tilby informasjon om mine API’er i henhold til en standard for å sikre at det blir enkelt å ta API’ene i bruk slik at vi bidrar til forenkling og samordning
API-tilbyder BTI010 Som API-tilbyder ønsker jeg å kunne se om andre tilbyr det samme eller nesten det samme som meg, så at det er mulig å harmonisere mellom “oss” [Livar: Case der det er fleire API-er som tilbyr det samme? Marit: Brreg og Skatt som har same datasett i FDK. Mathias: Felles studentsystem (FS) i UH-sektoren innheld personinformasjon. Kan ikkje konsoliderast med HR-data. Kan ikkje legge ned ein av dei. Dekker relasjonsfeltet i DCAT behovet?]
API-tilbyder BTI011 Som API-tilbyder/privat grossist (som er databehandler for innrapportering og tilgjengeliggjøring av informasjon), ønsker jeg at det finnes et forum / nettverk der dataeiere og databrukere utarbeider gode krav til tilgjengeliggjøring og tilbakerapportering av aggregert informasjon.
API-tilbyder BFP001: Som API-forvalter ønsker jeg at det knyttes opplysninger om sikkerhetsvurderinger tilknyttet felt i API’et (identifiserende, lokaliserende, krav til sikring, osv.) slik at hensyn til innebygd personvern i større grad er ivaretatt for det datasettet som publiseres.
API-tilbyder 1.Som API-forvalter ønsker jeg at katalogen dekker informasjonsbehovet til de som skal benytte API-ene jeg forvalter, slik at jeg slipper å besvare henvendelser fra dem/redusere antall henvendelser [frigjøre ressurser]
API-tilbyder 2. Som API-forvalter ønsker jeg at katalogen gir føringer for hvordan API-ene mine skal dokumenteres, etter “beste praksis”, så jeg slipper å sette meg inn i/holde meg oppdatert på hva som er beste praksis for API-dokumentasjon [frigjøre ressurser/bedre kvalitet]
API-tilbyder 3. Som API-forvalter ønsker jeg at katalogen og dens underliggende spesifikasjoner og standarder gir krav jeg kan bruke i avtaler med leverandører/anskaffelser slik at jeg slipper å sette meg inn i hvilke krav jeg bør stille.
API-tilbyder 4. Som API-forvalter ønsker jeg råd og forslag til avtaler med konsumenter slik at jeg kan gjøre flere API-er tilgjengelige for eksterne (f.eks. innovatører) og er trygg på å ha et godt avtaleverk og slipper å gjøre grunnarbeidet med vilkår og avtale for bruk.
API-tilbyder 5. Som API-forvalter ønsker jeg at API-katalogen kan vise min Swagger-dokumentasjon slik at jeg bare kan eksponere for eksempel Swagger-data (YAML) og slipper å drifte min egen Swagger UI-nettside. [relatert til Swagger-brukerhistorien, trur eg]
API-tilbyder 6. Som API-forvalter ønsker jeg at de aktivitetene jeg må gjøre og de standardene jeg må forholde meg til for å gjøre API-dokumentasjonen tilgjengelig i en nasjonal API-katalog, også gir verdi for andre, kommersielle, internasjonale API-kataloger, f.eks. synliggjøring på søkemotorer, ref Schema.orgs arbeid med vokabular for WebAPI http://pending.webschemas.org/WebAPI
API-tilbyder 7. Som API-forvalter har jeg behov for å selv velge hvor selve dokumentasjonen skal ligge, slik at jeg kan bruke de verktøyene som er mest hensiktsmessig til formålet.
API-tilbyder 8. Som API-forvalter som tilbyr data som ikke er åpne ønsker jeg å synliggjøre testmiljø for mine API-er slik at de er lette å oppdage for brukerne
API-tilbyder 9. Som API-forvalter ønsker jeg en felles løsning for API-dokumentasjon som er så god at jeg selv ønsker å bruke løsningen fremfor andre verktøy
API-tilbyder 10. Som en API-forvalter ønsker jeg å kunne ha “FAQ-funksjonalitet” (eller kunnskapsbase), slik at brukerne mine lettere kan få tak i svar på kjente utfordringer og jeg kan redusere kostnader ved å håndtere brukerhenvendelser.
API-tilbyder 11. Som API-forvalter/eier ønsker jeg å generere dokumentasjon ut fra koden eller tester, slik at jeg er sikker på at dokumentasjonen til enhver tid er oppdatert.
API-tilbyder 12. Som APi-forvalter/eier ønsker jeg at standarder og beskrivelser er helt maskinlesbare slik at høsting og bruk kan automatiseres og min rolle automatiseres bort eller erstattes av AI.
API-tilbyder 13. Som API-forvalter ønsker jeg å kunne påvirke utformingen av felles nasjonale oppskrifter for API-beskrivelser slik at de dekker mine behov.
API-tilbyder 14. Som API-forvalter/eier ønsker jeg en ensartet og samlet API-katalog slik at det blir enklere å publisere informasjonen.
API-tilbyder 15. Som API-forvalter/eier ønsker jeg en ensartet og samlet beskrivelse av alle våre API-er slik at det er enkelt for brukerne å gjenbruke sin kunnskap om de skal bruke flere API-er.
API-tilbyder 16. Som API-forvalter ønsker jeg å vite av hvem og hvor ofte mine API-er brukes (trafikkdata og bruksmønstre), slik at jeg optimere tilgang til API-er og ta stilling til hvilke API-er som eventuelt skal avvikles, samt kunne få grunnlag for å kunne rapportere på gevinstrealisering.
API-tilbyder 17. Som API-forvalter ønsker jeg å vise frem eksempel på bruk av mine API-er slik at verdien av API-ene blir synliggjort og det kan inspirere flere til å bruke API-ene og hvordan bruke API-ene.
API-tilbyder 18. Som API-forvalter ønsker jeg oversikt over integrasjoner mot mine API-er slik at konsekvenser og kostnader ved endringer kan forutses og minimeres.
API-tilbyder 19. Som API-forvalter ønsker jeg kontaktinfo til de som bruker mine API slik at jeg kan ta kontakt med de om brukerundersøkelser, driftsmeldinger, endring av API, nye API og liknande. [dersom jeg ikke har egne løsninger for dette allerede]
API-tilbyder 20. Som API-forvalter ønsker jeg at brukerne av mitt API skal ha en åpen kommunikasjon med meg og hverandre om hvilke behov de har som ikke er dekket i dag, slik at min videreutvikling treffer flest mulig brukere på en tilstrekkelig måte.
API-tilbyder 21. Som API-forvalter ønsker jeg å få en effektiv kanal for å få tilbakemeldinger og behov fra de som bruker API-ene mine, slik at det blir lettere å prioritere riktig ved videreutvikling av API-ene [styrke dialog med brukerne av API-ene]
API-tilbyder 22. Som en API-forvalter med allerede eksisterende API-katalog, ønsker jeg at løsningen er fleksibel(?)/legger til rette for automatisk høsting, slik at jeg kan vedlikeholde dokumentasjonen min lokalt.
API-tilbyder 23. Som API-forvalter ønsker jeg at de API-ene jeg tilbyr skal være lette å finne og ta i bruk for de som har verdi av dem, slik at innsatsen jeg har lagt ned i API-ene får størst mulig verdi [forsvare kostnadene ved utviklingen/forvaltningen av API-ene/generere størst mulig nytte]
API-tilbyder 24. Som API-forvalter (f.eks. av hotell.difi.no) ønsker jeg at API-ene er lette å finne og ta i bruk slik at verdien blir realisert.
API-tilbyder 25. Som API-forvalter som forvalter API-er til autoritative data ønsker jeg at API-katalogen skal prioritere presentasjon av mine API-er fremfor API-er som tilbyr samme data, men fra ikke-autoritative kilder, slik at API-brukerne ikke ubevisst bruker ikke-autoritative data
API-tilbyder 26. Som API-forvalter ønsker jeg at opplysninger som er relevante for datakatalogen og som finnes i API-et (feks “sist oppdatert”), høstes til datakatalogen slik at datasettbeskrivelsen er så god som mulig.
API-tilbyder 27. Som API-katalogeier ønsker jeg å koordinere beskrivelsene av API-ene som inngår i min katalog, slik at beskrivelsene fremstår som ensartet for de som skal benytte API-ene.
API-tilbyder 28. Som API-katalogeier ønsker jeg å, slik at jeg kan ha en total oversikt over API-ene våre kunne vite hvilke API-er min virksomhet tilbyr (og forvalte de på felles måte, vite hvem som bruker hvilke API-er osv.).
API-tilbyder 29. Som API-katalogeier med en eksisterende API-dokumentasjon ønsker jeg å bruke eksisterende API-dokumentasjon slik at jeg slipper å vedlikeholde API-dokumentasjon (manuelt) flere steder.
API-tilbyder 30. Som API-portaleier ønsker jeg at alle skal tilby sin informasjon på samme format, OG at alle har et eget API som beskriver sin katalog eller sitt API, slik at portalen enklest mulig kan høste og sammenstille informasjon om API-er.
API-tilbyder 31. Som API-portaleier ønsker jeg å få inn statistikk fra API-forvaltere slik at vi kan få et overordnet oversikt for hele sektoren/landet.
API-tilbyder 33. Som API-forvalter ønsker jeg at man tilbyr ei løsning/det blir spesifisert hvordan man skal tilby API på samme format.
API-tilbyder 34. Som API-katalogeier som ikke har en katalog, så ønsker jeg enkel måte å eksponere API-er på, ikke egen katalog med maskinlesbar beskrivelse, slik at jeg slipper å lage et eget verktøy med egne beskrivelser.
API-tilbyder 35. Som API-katalogeier ønsker jeg å kategorisere API-innslagene, slik at det kan differensieres mellom de.
API-tilbyder Som API-eier ønsker jeg å kunne beskrive funksjonaliteten i API-et på en overordnet måte slik at brukere får et innblikk i hva API-et innholder.
API-tilbyder Som API-eier ønsker jeg å kunne beskrive et API som ikke nødvendigvis kan knyttes til et datasett, slik at også dynamiske tjenester kan synliggjøres for andre konsumenter.
API-tilbyder Som API-eier ønsker jeg å angi at API’et skal være tilgjengelig i en runtime-tjenestekatalog (SMP/capability lookup) og Altinn tjenestekatalog/Authorization for samtykke og tilgangsstyring.
API-tilbyder Som API-katalogeier ønsker jeg å kategorisere API-innslagene, slik at det kan differensieres mellom de.
BTI006 Som kommunal API-konsument ønsker jeg digital tilgang til kommunesektorens rapporteringskategorier (f.eks. om rapportering er periodisk, om den er hendelsesutløst, eventuell dato for søknadsfrister) slik at jeg kan sikre at alle tidsfrister kan holdes API-tilbyder/private grossister
API-konsument (design time) BTI007 Som konsument av data fra kommunene ønsker jeg at kommunene tilbyr felles API for den samme informasjonen, uavhengig av hvilket fagsystem/hvilke leverandører de bruker for å forvalte informasjonen, slik at integrasjonen jeg utvikler mot én kommune kan gjenbrukes mot de resterende ca 400 kommunene.
API-konsument (design time) BFP002: Som API-konsument ønsker jeg enhetlig dokumentasjon og mulighet til “kundeservice” fra tjenesteleverandør.
API-konsument (design time) BFP003: Som API-konsument ønsker jeg å kunne se eventuelt tilknyttede informasjonsmodeller der det finnes, slik at jeg også kan finne og kvalitetssikre data og informasjon.
API-konsument (design time) BFP004: Som profesjonell API-konsument ønsker jeg stabile API som beskytter meg mot endringer i underliggende data slik at jeg trenger ikke å oppdatere apiene mine ved dataendringer.
API-konsument (design time) BFP005: Som API-konsument ønsker jeg at dokumentasjonen skal integreres i koden slik at den til enhver tid er oppdatert
API-konsument (design time) BFP006: Som API-konsument ønsker jeg at det ikke er for rigide krav til dokumentering og til selve APIet slik at det ikke hemmer rask utvikling av API
API-konsument (design time) BFP007: Som API-konsument ønsker jeg god og forutsigbar ytelse slik at det er lett å velge bruk av rett API som samsvarer med krav til andre API som inngår i tjenesten/prosessen
API-konsument (design time) BFP008: Som API-konsument ønsker jeg å vite oppdateringsfrekvens slik at jeg kan bestemme egen oppdatering.
API-konsument (design time) BFP009: Som API-konsument ønsker jeg å få dokumentere hvordan en kan oppdatere en egen kopi slik at en til hver tid bruker korrekte data.
API-konsument (design time) BFP010: Som API-konsument ønsker jeg å bare lese endringer som er gjort på siste oppdatering slik at vi slipper å lese hele datasettet.
API-konsument (design time) BFP011: Som API-konsument ønsker jeg et kontaktpunkt hos API-eier slik at man kan gi tilbakemelding og spørsmål.
API-konsument (design time) BFP012: Som API-konsument ønsker jeg varsel på endringer (push-varsel og toveiskommunikasjon) slik at jeg kan forberede tiltak.
API-konsument (design time) BFP013: Som API-konsument ønsker jeg en oversikt over tilgjengelige testmiljø for å teste ut apiene.
API-konsument (design time) BFP014: Som API-konsument ønsker jeg oversikt over tilgjengelige referanseimplementasjoner slik at jeg raskere kan komme i gang med å bruke apiene.
API-konsument (design time) BFP015: Som API-konsument ønsker jeg at nye versjoner av apiene blir gjort tilgjengelig før de settes i produksjon slik at jeg er forberedt.
API-konsument (design time) BFP016: Som API-konsument ønsker jeg en oversikt over hvilke versjoner som er tilgjengelig i hvilke miljø slik at jeg vet hva jeg kan teste mot. (prod og test)
API-konsument (design time) BFP017: Som API-konsument ønsker jeg en endringslogg så tidlig som mulig slik at jeg vet hva som har endret seg mellom versjoner.
API-konsument (design time) BFP018: Som API-konsument ønsker jeg at apiene inneholder referanser til lokale kodeverk som forklarer innholdet i apiene slik at jeg forstår detaljene i apiene.
API-konsument (design time) BFP019: Som API-konsument ønsker jeg at apiene inneholder referanser til begrepene som er brukt i apiene slik at jeg forstår detaljene og bruker dataene korrekt.
API-konsument (design time) BFP020: Som API-konsument ønsker jeg informasjon om oppdateringsfrekvens av dataene eller om dataene er statiske.
API-konsument (design time) BFP021: Som API-konsument ønsker jeg en standardisering av API-grensesnittene (inn og ut) slik at jeg kan ta i bruk nye datasett raskest mulig.
API-konsument (design time) BFP022: Som API-konsument ønsker jeg eksempler/mal på bruk slik at jeg kan ta i bruk nye datasett raskest mulig.
API-konsument (design time) BFP023: Som API-konsument ønsker jeg å se hvilken SLA som er forbundet med API et slik at jeg kan vurdere om det tilfredsstiller mine krav for bruk.
API-konsument (design time) BFP024: Som API-konsument ønsker jeg i de tilfeller hvor API er basert på et lukket datasett å koble meg til et miljø med syntetisk data for bruk i utvikling og test.
API-konsument (design time) BFP025: Som API-konsument ønsker jeg å se hvilke muligheter det finnes for konfigurasjon både hos meg og hos API-leverandør for å begrense tilgjengelig data til mitt faktiske formål. Kommentar: Dataminimering?
API-konsument (design time) BFP026: Som profesjonell API-konsument ønsker jeg forutsigbare økonomiske og juridiske rammer rundt (helst åpen/gratis) tilgang til offentlig data slik at jeg kan lage gode business cases.
API-konsument (design time) BFP027: Som API-konsument ønsker jeg at dokumentasjonen til API-er jeg skal bruke har informasjon om kvalitet og tilgjengelighet, slik at jeg slipper mange henvendelser til API-tilbyder for å få svar på enkle ting.
API-konsument (design time) BFP028: Som API-konsument ønsker jeg at API-et i større grad er “selvbeskrivende” og, dersom det brukes interne koder, at betydningen/forklaringen på disse er enkelt tilgjengelig, slik at jeg forstår hvordan jeg skal bruke API-et.
API-konsument (design time) BFP029: Som API-konsument ønsker jeg at offentlige dataeiere tilbyr APIer så tidlig som mulig (med tilsvarende varsling om datakvalitet) slik at jeg kan utvikle tjenester og bidra til kvalitetsforbedring av dataene.
API-konsument (design time) BFP030: Som API-konsument ønsker jeg å kunne spørre produsent om mer og bedre data slik at vi kan tilby et bedre og mer helhetlig bilde.
API-konsument (design time) BFP031: Som kommersiell API-konsument ønsker jeg at offentlige aktører ikke tilbyr konkurrerende verdiøkende tjenester på de API de tilbyr slik at jeg kan sikre min return on investment.
API-konsument (design time) BFP032: Som API-konsument ønsker jeg klar informasjon rundt lisensen på dataene APIet tilbyr for å raskt se om dette er forenlig med min bruk av dataene.
API-konsument (design time) BFP033: Som API-konsument ønsker jeg at API-et er avledet av en informasjonsmodell og Masterdata, som både sikrer konsistens mellom API og informasjonsmodell og gir mer og bedre dokumentasjon for API-et.
API-konsument (design time) BB1. Som API-konsument ønsker jeg et spørregrensesnitt (SQL-aktig/SPARQL/ODATA/GraphQL/NoSQL) mot API-et slik at jeg kan utforske datasettet og datasettets struktur/datamodell interaktivt som suplement til å lese dokumentasjon
API-konsument (design time) BB2. Som API-konsument ønsker jeg å gjøre spørringer og sammenstillinger og styre strukturen/formatet på resultatdatasettet selv, slik at jeg kan enkelt kan få det utsnittet av dataene som passer til den oppgaven jeg skal løse.
API-konsument (design time) BB3. Som API-konsument ønsker jeg å gjøre spørringer som gir meg dataene jeg har rettighet til å få (og ikke blir blokkert tilgang fordi API-et bare gir tilgang til mer data enn jeg har rettigheter til), slik at jeg kan få tilgang til data [rettigheter]
API-konsument (design time) BB4. Som API-konsument (ETL) ønsker jeg API-er som gir meg uttrekk som er tilpasset mine rettigheter og filtreringsbehov slik at jeg kan innhente uttrekket jeg trenger og har rett til. [rettigheter]
API-konsument (design time) BB5. Som API-konsument ønsker jeg å få tilgang til eksempler på bruk av API-et slik at jeg kan se mulighetene for bruk og bedre forstå hva API-et er ment å brukes til. [dokumentasjon]
API-konsument (design time) BB6. Som API-konsument ønsker jeg at semantikken rundt dataene er forklart (dataene er definert), slik at jeg kan ta et informert valg om å bruke dataene fordi jeg forstår kontekst, formål og omfanget av dem. [dokumentasjon]
API-konsument (design time) BB7. Som API-konsument ønsker jeg at det angis tydelig i dokumentasjonen hvilke data som er tilgjengelig, men også hva som ikke er tilgjengelig, slik at jeg slipper merarbeid pga. uklar dokumentasjon. [dokumentasjon]
API-konsument (design time) BB8. Som API-konsument ønsker jeg at utforskingsfasen/exploration/discovery gir meg rask oversikt og innsikt slik at jeg minimerer tiden jeg bruker på å velge et utsnitt eller må bruke egne verktøy for å skaffe meg oversikt. [dokumentasjon]
API-konsument (design time) BB9. Som API-konsument (datajournalist) ønsker jeg å få forklaringer/dokumentasjon på hvordan dataene henger sammen slik at jeg kan spare tid på semantisk fortolkning (kobling mot datakatalogen?) [dokumentasjon]
API-konsument (design time) BB10. Som API-konsument ønsker jeg mulighet til å innhente data om tekstdatasett slik at jeg kan lage analyser av disse og koble til andre kilde. [tekst som data]
API-konsument (design time) BB11. Som API-konsument (analytiker) ønsker jeg mulighet for å legg inn spørsmål, tips, eksempler knyttet til APIer slik at jeg kan øke min egen, andre brukere og api-forvalternes kjennskap om semantikk, selve APIen og bruk [økosystem]
API-konsument (design time) BB12. Som API-konsument ønsker jeg at API-ene støtter de “connector”-teknologiene som brukes av mine foretrukne verktøy for sammenstilling, analyse og visualisering, f.eks. Tableau, slik at jeg slipper å lage en mellomløsning/laste ned datasett for å analysere dem [samhandlingsevne]
API-konsument (design time) BB13. Som API-konsument ønsker jeg at de tjenestene offentlig sektor har utviklet på sine egne API gjøres tilgjengelig som åpen kildekode, slik at jeg kan gjenbruke relevante deler av koden for mitt eget konsum av API-et. [gjenbruk av kildekode]
API-konsument (design time) BB14. Som API-konsument ønsker jeg standardavtaler for både vilkår for bruk av data og tjeneste slik at jeg vet hvilke vilkår og tjenestenivå jeg har å forholde meg til. [databehandleravtaler, SLA]
API-konsument (design time) BB15. Som API-konsument ønsker jeg at relevante opplysninger som ikke er tilgjengelig i API-et er omtalt i dokumentasjonen, slik at jeg kan bruke API-et riktig. [dokumentasjon]
API-konsument (design time) BB16. Som API-konsument ønsker jeg at støttedatasett (f.eks. kodelister) er omtalt i dokumentasjonen slik at jeg kan anvende data fullt ut.[dokumentasjon]
API-konsument (design time) BB17. Som API-konsument ønsker jeg at spørringer, programkode og bibliotek som andre utvikler gjøres tilgjengelig som åpen kildekode slik at jeg kan dra nytte av disse i min prosess [gjenbruk av kildekode]
API-konsument (design time) BB18. Som API-konsument ønsker jeg at kildekoden til API-tjenesten er tilgjengelig som åpen kildekode, slik at jeg kan lese kildekode for å forstå APIet og kunne bruke det optimalt [dokumentasjon]
API-konsument (design time) BB19. Som API-konsument ønsker jeg å diskutere semantiske og tekniske spørsmål i en åpen kanal (wiki, github issues el liknende) for APIet jeg bruker, slik at brukerne kan hjelpe hverandre og tilbyder kan kommunisere åpent med sitt økosystem. [nettverk, dokumentasjon]
API-konsument (design time) BB20. Som API-konsument ønsker jeg eksempel på bruk av dataene som en del av dokumentasjonen av API-et, slik at de er enklere å fortså og ta i bruk [dokumentasjon]
API-konsument (design time) BB21. Som API-konsument ønsker jeg å kunne laste ned endringer i et datasett jeg allerede har en lokal kopi av slik at jeg effektivt kan vaske eget register basert på samme datakilde. [varsel]
API-konsument (design time) BB22. Som API-konsument ønsker jeg å få dokumentasjonen fra samme sted som jeg henter ut data, slik at jeg vet at det er oppdatert og lett tilgjengelig. [dokumentasjon]
API-konsument (design time) BB23. Som API-konsument (stordata) ønsker jeg tilgang til tekster i maskinlesbart format og under en åpen lisens slik at jeg fritt kan bruke tekster i maskinanalyse av språk eller lignende.[tekst som data]
API-konsument (design time) BB24. Som API-konsument (ETL) ønsker, jeg stabile API-er som er uavhengige av underliggende data slik at jeg ikke trenger å følge med endringer i data formater/strukturer. [forutsigbarhet]
API-konsument (design time) BB25. Som API-konsument (ETL) ønsker jeg mulighet til å abonnere på endringsvarslinger om både data og API-versjoner slik at jeg kan oppfriske data og/eller utnytte nye datafelter. [varsel]
API-konsument (design time) BB26. Som API-konsument ønsker jeg at API-ene jeg har tilgang til er de samme som API-forvalteren selv benytter til sin tjenesteutvikling, slik at jeg kan ha tillit til at forvaltning og videreutviklingen av API-ene gis prioritet og er verdt å bruke tid på å lære, gjøre bruk av [tjenestenivå/sla]
API-konsument (design time) BB27. Som API-konsument ønsker jeg å kunne laste ned en komplett versjon av datasettet i tillegg til API-funksjonalitet slik at jeg kan kjøre analyse på en lokal kopi av datasettet der dette er mest hensiktsmessig.[nedlasting]
API-konsument (design time) BB28. Som API-konsument ønsker jeg at API-et har god ytelse slik at jeg kan gjøre enkeltoppslag og ikke blir tvunget til å laste ned hele datasettet fordi API-et har lav ytelse. [tjenestenivå]
API-konsument (design time) BB29. Som API-konsument ønsker jeg en god mekanisme for å få beskjed om endringer i API eller dataformat (f.eks. ikke-brytende-endring som nye felt i dataformatet) slik at jeg kan tilpasse konsum av data når dataformatet blir endret eller utvidet.[varsel]
API-konsument (design time) BB30. Som API-konsument ønsker jeg å slippe å ha en kopi av xxregistreret eller datasettet slik at jeg kan være sikker på at dataene er oppdaterte. [tjenestenivå]
API-konsument (design time) BB31. Som API-konsument ønsker jeg at datasett som er gjort tilgjengelig for nedlasting har et forutsigbart URL-regime for siste versjon og historiske data slik at nedlasting kan automatiseres. [nedlasting, forutsigbarhet]
API-konsument (design time) BB32. Som API-konsument (datajournalist) ønsker jeg at strukturen i datasettene er stabile, slik at jeg ikke trenger gjøre endringer i min integrasjon/kode når nye versjoner hentes. [forutsigbarhet]
API-konsument (design time) BB33. Som API-konsument ønsker jeg å kunne laste ned kun endringer i et datasett for å oppdatere min lokale kopi av et datasett slik at jeg slipper å laste ned hele datasettet på nytt og import-jobben blir mindre. [varsel]
API-konsument (design time) BB34. Som API-konsument ønsker jeg å kunne se når hvilke deler av et datasett som er endret slik at jeg kan analysere endringer i data. [varsel]
API-konsument (design time) BB35. Som API-konsument ønsker jeg å kunne abonnere på hendelser slik at jeg får beskjed når hendelser oppstår. [varsel]
API-konsument (design time) BB36. Som API-konsument (ETL) ønsker jeg å unngå å laste komplette datasett og heller få de delene som har endret seg siden sist jeg lastet ned datasett slik at jeg minimerer egen ressursbruk. [varsel]
API-konsument (design time) BA1. Som API-konsument (student) ønsker jeg å filtrere på dataformater i oversikter over (åpne) API-er slik at jeg kan finne API-er i det formatet jeg ønsker å lære mer om eller filtrere ut de jeg ikke kan noe om.
API-konsument (design time) BA2. Som API-konsument ønsker jeg umiddelbar tilgang (slipper å vente på manuell tildeling av API-nøkler og tokens) til data (eller testdata) slik at jeg kan vurdere og eventuelt ta i bruk API-et umiddelbart.
API-konsument (design time) BA3. Som API-konsument ønsker jeg at det pekes til gode landingssider for API-et slik at jeg raskt settes i stand til å ta det i bruk.
API-konsument (design time) BA4. Som API-konsument ønsker jeg eksempler på API-requests slik at jeg kan komme fort i gang.
API-konsument (design time) BA5. Som API-konsument ønsker jeg at alle begreper linker direkte til en forklaring av begrepet slik at jeg slipper å lete gjennom dokumentasjonen. [kommentar: forskjell på begrep i den tekniske dokumentasjonen (f.eks. parameter i forespørsel) vs. begrep i datasettet (f.eks. fagtermer)]
API-konsument (design time) BA7. Som API-konsument ønsker jeg selvforklarende API-er slik at jeg kan komme raskt i gang, få raskt nytte av API-et.
API-konsument (design time) BA8. Som API-konsument ønsker jeg mulighet til enkelt å teste API-ene (utforske) f.eks. gjennom Swagger eller tilsvarende, slik at jeg raskere forstår API-et, og raskere klarer å bruke det (riktig) [ref BA7].
API-konsument (design time) BA9. Som API-konsument ønsker jeg at API-et er tilrettelagt for bruk, og ikke bare speiler innholdet i en database, slik at jeg kan slippe å forholde meg til et fagdomene, sette meg inn i interne kodeverk [brukerorientert, ikke avsenderstyrt …]
API-konsument (design time) BA10.Som API-konsument ønsker jeg en indikasjon på hvor dynamisk datasettet er, slik at jeg har en idé om hvor ofte jeg trenger å lese data på nytt.
API-konsument (design time) BA11. Som API-konsument ønsker jeg at jeg kan bytte til nye versjoner av API-et når det passer meg [Kommentar frå Livar: Litt usikker på denne. Her er det kanskje snakk om versjonering av API, at ein sjølv kan velje når tid ein byttar til ny versjon av API? I motsetnad til at eit API ikkje er versjonert og ved "breaking-changes" så må ein forholde seg til når API-et gjer eit brått hopp til ny versjon?]
API-konsument (design time) BA12. Som API-konsument ønsker jeg å hente inn data uavhengig av dataenes egentlig form slik at den ikke endrer seg når dataformatet endres.
API-konsument (design time) BA13. Som API-konsument ønsker jeg at Tableau/R/etc kan hente inn data for meg slik at jeg kan lage visualiseringer uten å måtte vite noe om API-er.
API-konsument (design time) BA14. Som API-konsument ønsker jeg lenker til applikasjoner som bruker datasettet, slik at jeg kan finne gode eksempler på bruk av API-et og datasettet. [kommentar: også programvarebibliotek og anna kodeverk som er relevant
API-konsument (design time) BA15. Som API-konsument ønsker jeg at alt jeg er avhengig av for applikasjonen min er tilgjengelig fra samme server, inklusive kodeverk, slik at CORS opprettholdes.
API-konsument (design time) BA16. Som API-konsument ønsker jeg at API-et tåler stor trafikk slik at jeg kan bruke API-et direkte i applikasjon
API-konsument (design time) BA17. Som API-konsument ønsker jeg beskrivelse av API-et sin kapasitet slik at jeg vet om jeg trenger en egen server for sluttbrukerapplikasjoner ved svært høy trafikk.
API-konsument (design time) BA18. Som API-konsument ønsker jeg lenker til aktuelle kodeverk (f.eks. kommunenummer, næringskoder) slik at jeg lett kan hente støtte-datasett og dermed benytte datasettet fullt ut.
API-konsument (design time) BA19. Som API-konsument ønsker jeg API der kodeverk (f.eks. kommunenummer, næringskoder) er en del av API-responsen slik at jeg slipper å utføre flere API-kall og hente fra ulike kilder for å få data jeg trenger.
API-konsument (design time) BA20. Som API-konsument ønsker jeg informasjon om hvor jeg kan finne statiske data som brukes til API-requests (Kommunenr, Kommunenavn..) slik at jeg slipper å lete etter dette selv.
API-konsument (design time) BA21. Som API-konsument ønsker jeg et API som gir godt strukturerte responser slik at data er lett å bruke.
API-konsument (design time) BA22. Som API-konsument (app-utvikler) ønsker jeg en landingsside hvor jeg kan stille spørsmål om bruk av API-et slik at jeg kan bruke det mest mulig hensiktsmessig, og gjerne med henvisninger til kjent brukt av API-et.
API-konsument (design time) BA23. Som API-konsument (app-utvikler) ønsker jeg en landingsside hvor jeg får tilgang til FAQ om API-et. [Kommentar: manglar “slik at <forretningsverdi>”]
API-konsument (design time) BA24. Som API-konsument ønsker jeg, når jeg får en respons fra et datasett, en henvisning til arkiverte versjoner av “det samme” datasettet (med elementer som ikke lenger finnes i det løpende datasettet), slik at jeg kan gi en mer komplett respons til brukeren.
API-konsument (design time) BA25. Som API-konsument ønsker jeg at beskrivelser av API-er som ikke lengre er tilgjengelige, skal fjernes fra API-katalogen, slik at jeg slipper å lese om API-er som jeg uansett ikke kan bruke.
API-konsument (design time) BA26. Som API-konsument ønsker jeg at API-et støtter CORS slik at jeg kan nå det fra en webapplikasjon uten å måtte gå via egen backend eller proxy.
API-konsument (design time) BA27. Som API-konsument ønsker jeg at API-forvaltere lærer av webutviklere og tenker på brukerinvolvering og brukertesting slik at jeg kan få et API-som er lagt til rette for bruk
API-konsument (design time) BA28. Som API-konsument ønsker jeg informasjon om ytelsesmessige (svartid, antall oppslag) begrensninger i API-et, slik at jeg kan vurdere om API-et har god nok ytelse til mitt formål.
API-konsument (design time) BA29. Som API-konsument ønsker jeg informasjon om hvordan jeg kan skaffe meg tilgang til API-er som ikke er offentlig tilgjengelig. [Kommentar: manglar “slik at <forretningsverdi>”]
API-konsument (design time) BA30. Som API-konsument ønsker jeg informasjon om hvilke hjemler som gir tilgang til API-er der tilgangen er begrenset, slik at jeg kan vurdere om min virksomhet har lov til å benytte API-et til det aktuelle formålet.
API-konsument (design time) BA31. Som API-konsument ønsker jeg informasjon om eventuelle økonomiske betingelser for bruk av API-er, slik at jeg kan vurdere hvorvidt det er aktuelt å betale for bruk av API-et.
API-konsument (design time) BA32. Som API-konsument (gründer) ønsker jeg en tematisk oversikt over offentlige API slik at jeg kan lage nye tjenester.
API-konsument (design time) BA33. Som API-konsument ønsker jeg at det er så få tekniske sperrer på API-ene som mulig slik at jeg kan ta det i bruk med minst mulig “prosess” mot API-forvalteren
API-konsument (design time) BA34. Som API-konsument ønsker jeg at eventuelle krav til API-nøkler etc lar seg løse raskt/selvbetjent slik at jeg kan komme i gang raskt. [f.eks. autorisering basert på eksisterende mekanismer fremfor å måtte kontakte forvalter og vente på svar (ID-porten, Altinn), bruksvilkår fremfor avtaler]
API-konsument (design time) BA35. Som API-konsument ønsker jeg at det er tydelig hva som er de rettslige rammene for bruk av API-ene slik at jeg kan være sikker på at jeg ikke kan få krav mot meg senere, f.eks. NLOD.
API-konsument (design time) BA36. Som API-konsument ønsker jeg at noen tar jobben med å holde oversikt over om API-er er tilgjengelige, utilgjengelige, stabilt, deprecated etc slik at jeg slipper å begynne å ta det i bruk først før jeg oppdager det.
API-konsument (design time) BA37. Som API-konsument ønsker jeg at tilgjengelige API-er er robuste slik at jeg kan anta at integrasjonen fungerer også ved høy trafikk
API-konsument (design time) BA38. Som API-konsument ønsker jeg (kanskje ....) HATEOAS og linked data-baserte API (for eks. JSON-LD/RDF-representasjoner) slik at jeg kan se hvilke opsjoner jeg har basert på de responsene jeg allerede har fått (den tilstanden jeg er i). [Kommentar frå Steinar: “basert på én informant ... han var tydelig på at han hadde gode erfaringer med API-er med RDF-data”]
API-konsument (design time) BA39. Som API-konsument ønsker jeg at begreper i API-ene er dokumentert slik at jeg forstår dokumentasjonen og bruker dataene i API-ene rett.
API-konsument (design time) BA40. Som API-tilbyder* ønsker jeg retningslinjer og beste praksis for dokumentasjon av API-ene mine slik at jeg kan dokumentere så effektivt og bra som mulig.
API-konsument (design time) BA41. Som API-konsument som benytter verktøy for å generere deler av kildekoden ønsker jeg at API-et er dokumentert iht “Open API Specification”, slik at jeg kan bruke kodegenereringsverktøy for å generere mye av den kildekoden som trengs for å bruke API-et fremfor å måtte skrive den selv [ref epost]
API-konsument (design time) BA42. Som API-konsument ønsker jeg varsler om “breaking changes” slik at jeg kan gjøre de nødvendige endringene før de brekker mine systemer/applikasjoner også. [f.eks. ved registrere e-postadresse]
API-konsument (design time) BA43. Som API-konsument ønsker jeg å bli varslet om at et API er “deprecated” (skal tas ut av bruk), slik at jeg kan oppdatere min applikasjon.
API-konsument (design time) BA44. Som API-konsument ønsker jeg intelligente API-er som kan f.eks. filtrere, aggrerere, gruppere slik at jeg bare få inn de resultater jeg trenger av hensyn til personvern, kapasitet etc.
API-konsument (design time) BA45. Som API-konsument ønsker jeg et API med gode muligheter for å filtrere data slik at jeg kan hente ut akkurat det utsnittet av datasettet som jeg trenger til mitt formål og slipper å gjøre ekstra prosessering av responsen jeg får fra API-et.
API-konsument (design time) BA46. Som API-konsument ønsker jeg mulighet for å bruke filtre i API-et slik at jeg kan ha bedre kontroll med hvilket utvalg av data jeg mottar, og ikke er avhengig av hvilke utvalg API-forvalteren har definert.
API-konsument (design time) BA48. Som API-konsument ønsker jeg at API-ene jeg bruker tilbyr komplett nedlasting av datasett slik at jeg kan bearbeide data lokalt.
API-konsument (design time) BA49. Som API-konsument ønsker jeg ikke å tvinges til å bruke API-er der hvor det aller enkleste for meg ville vært å få lastet ned hele datasettet. [kommentar: ønskjer i alle fall anledning til å velje]
API-konsument (design time) BA50. Som API-konsument, ønsker jeg å kunne gi tilbakemeldinger til god (eller dårlig) “beste praksis” for API-er, slik at dette kan være til hjelp for framtidige API-er som utvikles.
API-konsument (design time) BA51. Som API-konsument ønsker jeg mulighet til å gi tilbakemeldinger slik at jeg kan melde fra om feil eller foreslå forbedringer
API-konsument (design time) BA52. Som API-konsument ønsker jeg en enkel måte å rapportere inn feil i datakatalog (f.eks. Lenker som ikke fungerer) slik at jeg slipper å bla i utdatert innhold.
API-konsument (design time) BA6. Som API-konsument ønsker jeg å kunne på en enkel måte gi kontekstavhengige tilbakemeldinger til API-forvalteren, slik at dokumentasjonen og eller API-et blir bedre.
API-konsument (design time) BA47. Som API-konsument ønsker jeg at API-ene jeg skal bruke er så like som mulig (men så forskjellige som nødvendig), slik at jeg ikke trenger sette meg inn i unødvendig mye nytt for hvert API jeg skal vurdere eller bruke.
API-konsument (design time) BA53. Som API-konsument ønsker jeg at API-et støtter HTTP-standard med accept header for å velge data-format slik at kan gjøre det jeg er vant til.
API-konsument (design time) BA54. Som API-konsument ønsker jeg REST-API-er i tråd med REST-prinsippene/beste praksis slik at jeg kan bygge på erfaringene mine med andre REST-API-er, og forstå effekten av kallene i API-et med minst mulig teknisk dokumentasjon.
API-konsument (design time) BA55. Som API-konsument, ønsker jeg at API-et er designet etter en felles “beste praksis” som gjelder for API-er i API-katalogen, slik at jeg lett kjenner meg igjen på tvers av API-ene i katalogen.
API-konsument (design time) 32. Som API-bruker ønsker jeg å registrere en anvendelse slik at jeg kan oppgi den i API-kallet. Alternativt: Som API-forvalter ønsker jeg at brukere kan registrere seg med en ID som de bruker i API-kallet slik at jeg kan koble trafikk og anvendelse. [f.eks. ved overbruk av API-et kan man lett kontakte den som har satt opp anvendelsen]
API-konsument (design time) BFDK06 - Som arkitekt ønsker jeg å se hvilke data jeg må benytte for å gjøre oppslag mot et API og hvilke data jeg får tilbake slik at jeg kan planlegge design av løsning.
API-konsument (design time) BFDK10 - Som konsument ønsker jeg å få en liste over de datasett jeg vil ha tilgang til, presentert med grunnleggende informasjon om API slik at jeg sammenligne egenskaper (for eksempel hvilken protokoll som er brukt) ved API-ene
API-konsument (design time) BFDK11 - Som konsument ønsker jeg å abonnere på varslinger om etablering, endring, driftsstans og avvikling av API’er slik at jeg kan tilpasse meg endringer
API-konsument (design time) BFDK12 - Som konsument ønsker jeg kontaktinformasjon til brukerstøtte for API slik at jeg kan få hjelp
API-konsument (design time) BFDK13 - Som konsument av et åpent api ønsker jeg informasjon om hvor pålitelig leveransen av data er (forventet oppetid, responstid ved feil osb) slik at jeg kan gjøre en tilstrekkelig ROS-analyser for min integrasjon
API-konsument (design time) Som API-konsument ønsker jeg å vite hvilken interaksjonsform som tilbys i APIet (spørring, feed, fil) , slik at jeg kan vite om det dekker mine behov.
BTI007 Som konsument av data fra kommunene ønsker jeg at kommunene tilbyr felles API for den samme informasjonen, uavhengig av hvilket fagsystem/hvilke leverandører de bruker for å forvalte informasjonen, slik at integrasjonen jeg utvikler mot én kommune kan gjenbrukes mot de resterende ca 400 kommunene. API-tilbyder/private grossister
BTI008 Som konsument av data fra offentlige virksomheter ønsker jeg at de offentlige virksomhetene inngår avtaler med sine leverandører som gjør det tydelig hvem som eier dataene, og stiller krav til at de skal være gjøres tilgjengelige uten kostnader, slik at ikke den offentlige virksomheten hindres i å dele sine data med meg som følge av at kostnadene blir for store. API-tilbyder/private grossister
BTI009 Som konsument av offentlig data ønsker jeg en koordinert forvaltning av offentlig master data slik at jeg kan utvikle anvendelser/analyser med forutsigbar kvalitet og fornuftige økonomiske og juridiske betingelser. API-tilbyder/private grossister
API-tilbyder/private grossister BTI002 Som API-tilbyder som sammenstiller data på vegne av f.eks. kommuner ønsker jeg at de større systemene og registrene skal tilby API-er slik at jeg enkelt kan få tilgang til dataene for å gjennomføre mitt oppdrag.
API-tilbyder/private grossister BTI004 Som API-tilbyder ønsker jeg å tilby informasjon om mine API’er i henhold til en standard for å redusere mine forvaltningskostnader, for eksempel for å få redusert manuelle henvendelser
API-tilbyder/private grossister BTI005 Som API-tilbyder ønsker jeg å tilby informasjon om mine API’er i henhold til en standard for å sikre at det blir enkelt å ta API’ene i bruk slik at vi bidrar til forenkling og samordning
API-tilbyder/private grossister BTI011 Som API-tilbyder/privat grossist (som er databehandler for innrapportering og tilgjengeliggjøring av informasjon), ønsker jeg at det finnes et forum / nettverk der dataeiere og databrukere utarbeider gode krav til tilgjengeliggjøring og tilbakerapportering av aggregert informasjon.
BTI010 Som API-tilbyder ønsker jeg å kunne se om andre tilbyr det samme eller nesten det samme som meg, så at det er mulig å harmonisere mellom “oss” [Livar: Case der det er fleire API-er som tilbyr det samme? Marit: Brreg og Skatt som har same datasett i FDK. Mathias: Felles studentsystem (FS) i UH-sektoren innheld personinformasjon. Kan ikkje konsoliderast med HR-data. Kan ikkje legge ned ein av dei. Dekker relasjonsfeltet i DCAT behovet?] API-tilbyder/private grossister
Eg vil bruke ei bildelingsteneste for å leige ut min bil. Der vil eg gje samtykke til å hente data frå vegvesenet sitt køyretøysregister om kva bilar eg eig, så slepp eg å taste inn informasjonen sjølv, og kan i staden få ferdig utfylt informasjon om kva bil det er, modell etc. Bildelingstenesten kan vidare nytte informasjonen til å hente inn informasjon om mine bilar, til dømes bilde av bilen, så eg slepp å legge inn dette sjølv. Som sluttbruker ønsker jeg å gi samtykke til at en 3dje part kan innhente mine data fra offentlig myndighet slik at jeg slipper å tilgjengeliggjøre dataene selv
“Den registrerte/subjektet” Jeg ønsker å få kontinuerlig økonomisk og rettslig rådgivning fra “velferdsrådgiverne A/S”, slik at de kan identifisere hvilke offentlige tjenester jeg har rett på, evt anbefale meg å jobbe litt mindre slik at jeg kommer under inntektsgrenser som igjen trigger nye utbetalinger -- jobbe mindre og tjene mere!
“Den registrerte/subjektet” Som sluttbruker ønsker jeg å gi samtykke til at en 3dje part kan innhente mine data fra offentlig myndighet slik at jeg slipper å tilgjengeliggjøre dataene selv
“Den registrerte/subjektet” Som sluttbruker ønsker jeg å gi samtykke til at en offentlig myndighet kan innhente mine data fra en 3dje part slik at jeg slipper å tilgjengegliggjøre dataene selv.
“Den registrerte/subjektet” Som sluttbruker ønsker jeg at en offentlig aktør skal ha tilgang til data om meg hos en annen offentlig aktør
“Den registrerte/subjektet” Som sluttbruker ønsker jeg at en privat virksomhet skal ha tilgang til data om meg fra en tredjepart (app) slik at jeg kan slippe å tiljgengeliggjøre dataene selv
MyData, viderebruk av personopplysninger Eg vil bruke ei bildelingsteneste for å leige ut min bil. Der vil eg gje samtykke til å hente data frå vegvesenet sitt køyretøysregister om kva bilar eg eig, så slepp eg å taste inn informasjonen sjølv, og kan i staden få ferdig utfylt informasjon om kva bil det er, modell etc. Bildelingstenesten kan vidare nytte informasjonen til å hente inn informasjon om mine bilar, til dømes bilde av bilen, så eg slepp å legge inn dette sjølv.
MyData, viderebruk av personopplysninger Som deltakar i ein treningsaksjon, f.eks. Sykletiljobben eller sprekere.no, ønskjer eg å kunne gje treningstenesta tilgang til informasjon om kven som er min arbeidsgjevar, slik at eg kan bli med i ei gruppe for min arbeidsplass og skape intern konkurranse, i staden for at eg må manuelt bli med i grupper, nokon på arbeidsplassen må legge meg til manuelt og bruke mykje tid på ajourhald av dette.
MyData, viderebruk av personopplysninger Som sykkeleier vil jeg ha automatisert innfylling av tapsmelding til forsikringsselskapet fra innmeldte sak til politiet for å sikre konsistens og spare tid.
Som deltakar i ein treningsaksjon, f.eks. Sykletiljobben eller sprekere.no, ønskjer eg å kunne gje treningstenesta tilgang til informasjon om kven som er min arbeidsgjevar, slik at eg kan bli med i ei gruppe for min arbeidsplass og skape intern konkurranse, i staden for at eg må manuelt bli med i grupper, nokon på arbeidsplassen må legge meg til manuelt og bruke mykje tid på ajourhald av dette. Som sluttbruker ønsker jeg å gi samtykke til at en 3dje part kan innhente mine data fra offentlig myndighet slik at jeg slipper å tilgjengeliggjøre dataene selv
Som brukar er eg villig til å dele mine posisjonsdata slik at ein kan verifisere at eg har tatt buss-reiser og dermed …. kan eg få statistikk om kor mykje eg har reist kollektivt og dette kan brukast til … Premisset for dette er at alle bussar som køyrer kollektivtrafikk har ordentleg GPS-sporing, og at ein har tilgang til historiske posisjonsdata for bussane slik at ein kan kryssjekke kvar og når bussane faktisk har køyrt med mine personlege posisjonsdata. MyData, viderebruk av personopplysninger
Som brukar er eg villig til å dele mine posisjonsdata slik at ein kan verifisere at eg har tatt buss-reiser og dermed …. kan eg få statistikk om kor mykje eg har reist kollektivt og dette kan brukast til … Premisset for dette er at alle bussar som køyrer kollektivtrafikk har ordentleg GPS-sporing, og at ein har tilgang til historiske posisjonsdata for bussane slik at ein kan kryssjekke kvar og når bussane faktisk har køyrt med mine personlege posisjonsdata. Som sluttbruker ønsker jeg å gi samtykke til at en offentlig myndighet kan innhente mine data fra en 3dje part slik at jeg slipper å tilgjengegliggjøre dataene selv.
Som befolkning i et område vil vi gi bevegelsesinformasjon (fra telefon, gpx, google location history osv.) til en kommune for bedre planlegging av a) utbygging av sykkel/turveier b) vedlikehold c) øvrig kommunale tjenester. MyData, viderebruk av personopplysninger
Som befolkning i et område vil vi gi bevegelsesinformasjon (fra telefon, gpx, google location history osv.) til en kommune for bedre planlegging av a) utbygging av sykkel/turveier b) vedlikehold c) øvrig kommunale tjenester. Som sluttbruker ønsker jeg å gi samtykke til at en offentlig myndighet kan innhente mine data fra en 3dje part slik at jeg slipper å tilgjengegliggjøre dataene selv.
Som pasient vil jeg at fastlegen skal ha tilgang til treningsdata (helst AI bearbeidet) (med automatisert varsling om avvik?) for å bidra til bedre, raskere og billigere diagnostisering MyData, viderebruk av personopplysninger
Som pasient vil jeg at fastlegen skal ha tilgang til treningsdata (helst AI bearbeidet) (med automatisert varsling om avvik?) for å bidra til bedre, raskere og billigere diagnostisering Som sluttbruker ønsker jeg å gi samtykke til at en offentlig myndighet kan innhente mine data fra en 3dje part slik at jeg slipper å tilgjengegliggjøre dataene selv.
Som sykkeleier vil jeg ha automatisert innfylling av tapsmelding til forsikringsselskapet fra innmeldte sak til politiet for å sikre konsistens og spare tid. Som sluttbruker ønsker jeg å gi samtykke til at en 3dje part kan innhente mine data fra offentlig myndighet slik at jeg slipper å tilgjengeliggjøre dataene selv
Fra BRREGs arbeid: Registrere seg som Über-sjåfør (dokumentere førerkort) MyData, viderebruk av personopplysninger
Fra BRREGs arbeid: Registrere seg som Über-sjåfør (dokumentere førerkort) Som sluttbruker ønsker jeg å gi samtykke til at en 3dje part kan innhente mine data fra offentlig myndighet slik at jeg slipper å tilgjengeliggjøre dataene selv
Når Oslo kommune trenger data om hvordan jeg beveger meg -- for å drive byutvikling, prioritere sykkelstier m.m., kan jeg gi dem mine Strava-data MyData, viderebruk av personopplysninger
Når Oslo kommune trenger data om hvordan jeg beveger meg -- for å drive byutvikling, prioritere sykkelstier m.m., kan jeg gi dem mine Strava-data Som sluttbruker ønsker jeg å gi samtykke til at en offentlig myndighet kan innhente mine data fra en 3dje part slik at jeg slipper å tilgjengegliggjøre dataene selv.
Når jeg flytter til en ny kommune/et nytt sted, vil jeg bli spurt om jeg ønsker å bytte til ny fastlege på mitt nye bosted, med en oversikt over tilgjengelige fastleger med ledig kapasitet. MyData, viderebruk av personopplysninger
Når jeg flytter til en ny kommune/et nytt sted, vil jeg bli spurt om jeg ønsker å bytte til ny fastlege på mitt nye bosted, med en oversikt over tilgjengelige fastleger med ledig kapasitet. Som sluttbruker ønsker jeg at en offentlig aktør skal ha tilgang til data om meg hos en annen offentlig aktør
Når jeg flytter til en ny kommune ønsker jeg at mine data fra gamlekommunen automatisk overføres slik at min nye kommune har oversikt over hvilke behov og tilbud som er relevant for meg. MyData, viderebruk av personopplysninger
Når jeg flytter til en ny kommune ønsker jeg at mine data fra gamlekommunen automatisk overføres slik at min nye kommune har oversikt over hvilke behov og tilbud som er relevant for meg. Som sluttbruker ønsker jeg at en offentlig aktør skal ha tilgang til data om meg hos en annen offentlig aktør
Jeg ønsker å få tilgang til reisedata (tid, pris, fra-til-sted osv) for ulike transporttjenester slik at jeg kan bruke data i stedet for kvitteringer ved innlevering av reiseregninger. MyData, viderebruk av personopplysninger
Jeg ønsker å få tilgang til reisedata (tid, pris, fra-til-sted osv) for ulike transporttjenester slik at jeg kan bruke data i stedet for kvitteringer ved innlevering av reiseregninger. Som sluttbruker ønsker jeg at en privat virksomhet skal ha tilgang til data om meg fra en tredjepart (app) slik at jeg kan slippe å tiljgengeliggjøre dataene selv
Jeg lurer på om Osloskolen klarer å få mine barn til å reaching their full potential, og ønsker at en fancy ny utdanningstjeneste skal få tilgang til alle data Osloskolen har om mitt barns oppgaveløsning, f.eks. Hvor lang tid de bruker på ulike typer oppgaver, slik at dataene kan analyseres og jeg kan få et skreddersydd opplegg. MyData, viderebruk av personopplysninger
Jeg lurer på om Osloskolen klarer å få mine barn til å reaching their full potential, og ønsker at en fancy ny utdanningstjeneste skal få tilgang til alle data Osloskolen har om mitt barns oppgaveløsning, f.eks. Hvor lang tid de bruker på ulike typer oppgaver, slik at dataene kan analyseres og jeg kan få et skreddersydd opplegg. Som sluttbruker ønsker jeg at en offentlig aktør skal ha tilgang til data om meg hos en annen offentlig aktør
Jeg ønsker å få kontinuerlig økonomisk og rettslig rådgivning fra “velferdsrådgiverne A/S”, slik at de kan identifisere hvilke offentlige tjenester jeg har rett på, evt anbefale meg å jobbe litt mindre slik at jeg kommer under inntektsgrenser som igjen trigger nye utbetalinger -- jobbe mindre og tjene mere! MyData, viderebruk av personopplysninger
Som arbeidstager ønsker jeg å få automatisk utfylt reiseregning når jeg sykler, dokumentert med lokasjonsdata fra min mobil MyData, viderebruk av personopplysninger
Som arbeidstager ønsker jeg å få automatisk utfylt reiseregning når jeg sykler, dokumentert med lokasjonsdata fra min mobil Som sluttbruker ønsker jeg at en privat virksomhet skal ha tilgang til data om meg fra en tredjepart (app) slik at jeg kan slippe å tiljgengeliggjøre dataene selv
Når jeg kjøper noe i en nettbutikk vil jeg at de nødvendige personalia blir fylt ut automatisk, så lite som mulig, men nok at butikken får sendt produktene til riktig adresse. MyData, viderebruk av personopplysninger
Når jeg kjøper noe i en nettbutikk vil jeg at de nødvendige personalia blir fylt ut automatisk, så lite som mulig, men nok at butikken får sendt produktene til riktig adresse. Som sluttbruker ønsker jeg å gi samtykke til at en 3dje part kan innhente mine data fra offentlig myndighet slik at jeg slipper å tilgjengeliggjøre dataene selv
BAM01 - Som ansvarlig for API-management ønsker jeg å publisere mine API i en API-katalog slik at utviklere raskt kan finne frem til mitt API/økt synlighet API-management
BAM02 - Som ansvarlig for API-management ønsker jeg å dokumentere mitt API slik at utviklere raskt kan benytte API-et for tilgang til de data API-et representerer API-management
BAM03 - Som ansvarlig for API-management ønsker jeg å notifisere endringer i mine API til dem som benytter API-ene slik at man ikke bryter kontrakter API-management
BAM04 - Som leverandør av API-management-verktøy ønsker jeg at jeg å kunne tilby automatisk integrasjon med den felles API-katalogen slik at jeg kan selge mer av produktet mitt ved å vise til at det støtter opp under de nasjonale føringene. API-management
BAM05 - Som leverandør av API-management-verktøy ønsker jeg at den felles API-katalogen støtter beste praksis for API-er og de mest utbredte standardene, slik at det blir lett for meg å integrere mitt verktøy med den felles API-katalogen [gjetter jeg på …] API-management
BAM06 - Som ansvarlig for API-management ønsker jeg å kunne fordele eierskap og ansvar for de enkelte API-ene til det forretningsområdet som er dataforvalter/dataeier, slik at de kan være mest mulig selvbetjente og redusere flaskehalser (“publisher portal”)/sikre nærhet og dermed kvalitet (ansvarliggjøring av den rette aktøren) API-management
API-katalogen BTI004 Som API-tilbyder ønsker jeg å tilby informasjon om mine API’er i henhold til en standard for å redusere mine forvaltningskostnader, for eksempel for å få redusert manuelle henvendelser
API-katalogen BTI005 Som API-tilbyder ønsker jeg å tilby informasjon om mine API’er i henhold til en standard for å sikre at det blir enkelt å ta API’ene i bruk slik at vi bidrar til forenkling og samordning
API-katalogen BTI010 Som API-tilbyder ønsker jeg å kunne se om andre tilbyr det samme eller nesten det samme som meg, så at det er mulig å harmonisere mellom “oss” [Livar: Case der det er fleire API-er som tilbyr det samme? Marit: Brreg og Skatt som har same datasett i FDK. Mathias: Felles studentsystem (FS) i UH-sektoren innheld personinformasjon. Kan ikkje konsoliderast med HR-data. Kan ikkje legge ned ein av dei. Dekker relasjonsfeltet i DCAT behovet?]
API-katalogen BAM01 - Som ansvarlig for API-management ønsker jeg å publisere mine API i en API-katalog slik at utviklere raskt kan finne frem til mitt API/økt synlighet
API-katalogen BAM03 - Som ansvarlig for API-management ønsker jeg å notifisere endringer i mine API til dem som benytter API-ene slik at man ikke bryter kontrakter
API-katalogen BAM04 - Som leverandør av API-management-verktøy ønsker jeg at jeg å kunne tilby automatisk integrasjon med den felles API-katalogen slik at jeg kan selge mer av produktet mitt ved å vise til at det støtter opp under de nasjonale føringene.
API-katalogen BAM07 - Som leverandør av API-management-verktøy ønsker jeg å kunne publisere dokumentasjon om API fra mitt API management verktøy til en felles offentlig API katalog
API-katalogen BAM08 - Som ansvarlig for API-management ønsker jeg oversikt over brukerne av mitt API slik at jeg kan formidle endringer i APIet. [Livar: duplikat av BAM03?]
API-katalogen BAM13 - Som ansvarlig for API-management ønsker jeg at brukerne av mine API-er skal kunne gi innspill til endringer av mine API-er, slik at jeg gjøre API-ene mine mer brukervennlige.
API-katalogen BB8. Som API-konsument ønsker jeg at utforskingsfasen/exploration/discovery gir meg rask oversikt og innsikt slik at jeg minimerer tiden jeg bruker på å velge et utsnitt eller må bruke egne verktøy for å skaffe meg oversikt. [dokumentasjon]
API-katalogen BB10. Som API-konsument ønsker jeg mulighet til å innhente data om tekstdatasett slik at jeg kan lage analyser av disse og koble til andre kilde. [tekst som data]
API-katalogen BB11. Som API-konsument (analytiker) ønsker jeg mulighet for å legg inn spørsmål, tips, eksempler knyttet til APIer slik at jeg kan øke min egen, andre brukere og api-forvalternes kjennskap om semantikk, selve APIen og bruk [økosystem]
API-katalogen BB19. Som API-konsument ønsker jeg å diskutere semantiske og tekniske spørsmål i en åpen kanal (wiki, github issues el liknende) for APIet jeg bruker, slik at brukerne kan hjelpe hverandre og tilbyder kan kommunisere åpent med sitt økosystem. [nettverk, dokumentasjon]
API-katalogen BB20. Som API-konsument ønsker jeg eksempel på bruk av dataene som en del av dokumentasjonen av API-et, slik at de er enklere å fortså og ta i bruk [dokumentasjon]
API-katalogen BA1. Som API-konsument (student) ønsker jeg å filtrere på dataformater i oversikter over (åpne) API-er slik at jeg kan finne API-er i det formatet jeg ønsker å lære mer om eller filtrere ut de jeg ikke kan noe om.
API-katalogen BA14. Som API-konsument ønsker jeg lenker til applikasjoner som bruker datasettet, slik at jeg kan finne gode eksempler på bruk av API-et og datasettet. [kommentar: også programvarebibliotek og anna kodeverk som er relevant
API-katalogen BA20. Som API-konsument ønsker jeg informasjon om hvor jeg kan finne statiske data som brukes til API-requests (Kommunenr, Kommunenavn..) slik at jeg slipper å lete etter dette selv.
API-katalogen BA22. Som API-konsument (app-utvikler) ønsker jeg en landingsside hvor jeg kan stille spørsmål om bruk av API-et slik at jeg kan bruke det mest mulig hensiktsmessig, og gjerne med henvisninger til kjent brukt av API-et.
API-katalogen BA25. Som API-konsument ønsker jeg at beskrivelser av API-er som ikke lengre er tilgjengelige, skal fjernes fra API-katalogen, slik at jeg slipper å lese om API-er som jeg uansett ikke kan bruke.
API-katalogen BA36. Som API-konsument ønsker jeg at noen tar jobben med å holde oversikt over om API-er er tilgjengelige, utilgjengelige, stabilt, deprecated etc slik at jeg slipper å begynne å ta det i bruk først før jeg oppdager det.
API-katalogen BA42. Som API-konsument ønsker jeg varsler om “breaking changes” slik at jeg kan gjøre de nødvendige endringene før de brekker mine systemer/applikasjoner også. [f.eks. ved registrere e-postadresse]
API-katalogen BA43. Som API-konsument ønsker jeg å bli varslet om at et API er “deprecated” (skal tas ut av bruk), slik at jeg kan oppdatere min applikasjon.
API-katalogen BA50. Som API-konsument, ønsker jeg å kunne gi tilbakemeldinger til god (eller dårlig) “beste praksis” for API-er, slik at dette kan være til hjelp for framtidige API-er som utvikles.
API-katalogen BA51. Som API-konsument ønsker jeg mulighet til å gi tilbakemeldinger slik at jeg kan melde fra om feil eller foreslå forbedringer
API-katalogen BA52. Som API-konsument ønsker jeg en enkel måte å rapportere inn feil i datakatalog (f.eks. Lenker som ikke fungerer) slik at jeg slipper å bla i utdatert innhold.
API-katalogen BA6. Som API-konsument ønsker jeg å kunne på en enkel måte gi kontekstavhengige tilbakemeldinger til API-forvalteren, slik at dokumentasjonen og eller API-et blir bedre.
API-katalogen 1.Som API-forvalter ønsker jeg at katalogen dekker informasjonsbehovet til de som skal benytte API-ene jeg forvalter, slik at jeg slipper å besvare henvendelser fra dem/redusere antall henvendelser [frigjøre ressurser]
API-katalogen 5. Som API-forvalter ønsker jeg at API-katalogen kan vise min Swagger-dokumentasjon slik at jeg bare kan eksponere for eksempel Swagger-data (YAML) og slipper å drifte min egen Swagger UI-nettside. [relatert til Swagger-brukerhistorien, trur eg]
API-katalogen 7. Som API-forvalter har jeg behov for å selv velge hvor selve dokumentasjonen skal ligge, slik at jeg kan bruke de verktøyene som er mest hensiktsmessig til formålet.
API-katalogen 9. Som API-forvalter ønsker jeg en felles løsning for API-dokumentasjon som er så god at jeg selv ønsker å bruke løsningen fremfor andre verktøy
API-katalogen 10. Som en API-forvalter ønsker jeg å kunne ha “FAQ-funksjonalitet” (eller kunnskapsbase), slik at brukerne mine lettere kan få tak i svar på kjente utfordringer og jeg kan redusere kostnader ved å håndtere brukerhenvendelser.
API-katalogen 12. Som APi-forvalter/eier ønsker jeg at standarder og beskrivelser er helt maskinlesbare slik at høsting og bruk kan automatiseres og min rolle automatiseres bort eller erstattes av AI.
API-katalogen 14. Som API-forvalter/eier ønsker jeg en ensartet og samlet API-katalog slik at det blir enklere å publisere informasjonen.
API-katalogen 15. Som API-forvalter/eier ønsker jeg en ensartet og samlet beskrivelse av alle våre API-er slik at det er enkelt for brukerne å gjenbruke sin kunnskap om de skal bruke flere API-er.
API-katalogen 16. Som API-forvalter ønsker jeg å vite av hvem og hvor ofte mine API-er brukes (trafikkdata og bruksmønstre), slik at jeg optimere tilgang til API-er og ta stilling til hvilke API-er som eventuelt skal avvikles, samt kunne få grunnlag for å kunne rapportere på gevinstrealisering.
API-katalogen 17. Som API-forvalter ønsker jeg å vise frem eksempel på bruk av mine API-er slik at verdien av API-ene blir synliggjort og det kan inspirere flere til å bruke API-ene og hvordan bruke API-ene.
API-katalogen 18. Som API-forvalter ønsker jeg oversikt over integrasjoner mot mine API-er slik at konsekvenser og kostnader ved endringer kan forutses og minimeres.
API-katalogen 20. Som API-forvalter ønsker jeg at brukerne av mitt API skal ha en åpen kommunikasjon med meg og hverandre om hvilke behov de har som ikke er dekket i dag, slik at min videreutvikling treffer flest mulig brukere på en tilstrekkelig måte.
API-katalogen 21. Som API-forvalter ønsker jeg å få en effektiv kanal for å få tilbakemeldinger og behov fra de som bruker API-ene mine, slik at det blir lettere å prioritere riktig ved videreutvikling av API-ene [styrke dialog med brukerne av API-ene]
API-katalogen 22. Som en API-forvalter med allerede eksisterende API-katalog, ønsker jeg at løsningen er fleksibel(?)/legger til rette for automatisk høsting, slik at jeg kan vedlikeholde dokumentasjonen min lokalt.
API-katalogen 23. Som API-forvalter ønsker jeg at de API-ene jeg tilbyr skal være lette å finne og ta i bruk for de som har verdi av dem, slik at innsatsen jeg har lagt ned i API-ene får størst mulig verdi [forsvare kostnadene ved utviklingen/forvaltningen av API-ene/generere størst mulig nytte]
API-katalogen 24. Som API-forvalter (f.eks. av hotell.difi.no) ønsker jeg at API-ene er lette å finne og ta i bruk slik at verdien blir realisert.
API-katalogen 25. Som API-forvalter som forvalter API-er til autoritative data ønsker jeg at API-katalogen skal prioritere presentasjon av mine API-er fremfor API-er som tilbyr samme data, men fra ikke-autoritative kilder, slik at API-brukerne ikke ubevisst bruker ikke-autoritative data
API-katalogen 26. Som API-forvalter ønsker jeg at opplysninger som er relevante for datakatalogen og som finnes i API-et (feks “sist oppdatert”), høstes til datakatalogen slik at datasettbeskrivelsen er så god som mulig.
API-katalogen 28. Som API-katalogeier ønsker jeg å, slik at jeg kan ha en total oversikt over API-ene våre kunne vite hvilke API-er min virksomhet tilbyr (og forvalte de på felles måte, vite hvem som bruker hvilke API-er osv.).
API-katalogen 29. Som API-katalogeier med en eksisterende API-dokumentasjon ønsker jeg å bruke eksisterende API-dokumentasjon slik at jeg slipper å vedlikeholde API-dokumentasjon (manuelt) flere steder.
API-katalogen 30. Som API-portaleier ønsker jeg at alle skal tilby sin informasjon på samme format, OG at alle har et eget API som beskriver sin katalog eller sitt API, slik at portalen enklest mulig kan høste og sammenstille informasjon om API-er.
API-katalogen 31. Som API-portaleier ønsker jeg å få inn statistikk fra API-forvaltere slik at vi kan få et overordnet oversikt for hele sektoren/landet.
API-katalogen 32. Som API-bruker ønsker jeg å registrere en anvendelse slik at jeg kan oppgi den i API-kallet. Alternativt: Som API-forvalter ønsker jeg at brukere kan registrere seg med en ID som de bruker i API-kallet slik at jeg kan koble trafikk og anvendelse. [f.eks. ved overbruk av API-et kan man lett kontakte den som har satt opp anvendelsen]
API-katalogen 34. Som API-katalogeier som ikke har en katalog, så ønsker jeg enkel måte å eksponere API-er på, ikke egen katalog med maskinlesbar beskrivelse, slik at jeg slipper å lage et eget verktøy med egne beskrivelser.
API-katalogen 35. Som API-katalogeier ønsker jeg å kategorisere API-innslagene, slik at det kan differensieres mellom de.
API-katalogen BFDK01 - Som forretningsutvikler ønsker jeg å se hvilke datasett som tilbyr API, slik at jeg kan vurdere om det kan brukes i mine tjenester.
API-katalogen BFDK02 - Som forretningsutvikler ønsker jeg å søke etter API, slik at jeg raskt kan finne ut om det finnes data jeg kan gjenbruke
API-katalogen BFDK03 - Som forretningsutvikler ønsker jeg å se detaljerte beskrivelser av APIene, slik at jeg kan vurdere om de er av tilstrekkelig kvalitet for bruk i mine tjenester
API-katalogen BFDK04 - Som forretningsutvikler ønsker jeg å filtrere på datasett som har API, slik at jeg bedre treff på mine søk i katalogen.
API-katalogen BFDK05 - Som forretningsutvikler ønsker jeg å kunne sammenligne APIere, slik at jeg vurdere om et API passer bedre enn et annet for min bruk.
API-katalogen BFDK07 - Som datasetteier (og som beskriver datasett i datakatalogen) ønsker jeg å kunne kople beskrivelser av APIer (i flertall) til et gitt datasett, slik at jeg kan vise hvilke distribusjoner som finnes av et datasett
API-katalogen BFDK06 - Som arkitekt ønsker jeg å se hvilke data jeg må benytte for å gjøre oppslag mot et API og hvilke data jeg får tilbake slik at jeg kan planlegge design av løsning.
API-katalogen BFDK08 - Som datasetteier (som beskriver datasett i datakatalogen) ønsker jeg å kunne plukke fra API-beskrivelsen dataelementene som jeg ønsker å ta med i datasettbeskrivelsen, slik at dataelementene jeg tar med gjenspeiler det som APIet virkelig kan tilby.
API-katalogen BFDK09 - Som datasetteier for historiske (avleverte) data ønsker jeg å kunne koble de historiske datasettene med tilsvarende aktive/nåværende datasett, slik at jeg kan tilby brukerne en helhetlig tilgang til dataene.
API-katalogen BFDK10 - Som konsument ønsker jeg å få en liste over de datasett jeg vil ha tilgang til, presentert med grunnleggende informasjon om API slik at jeg sammenligne egenskaper (for eksempel hvilken protokoll som er brukt) ved API-ene
API-katalogen BFDK11 - Som konsument ønsker jeg å abonnere på varslinger om etablering, endring, driftsstans og avvikling av API’er slik at jeg kan tilpasse meg endringer
API-katalogen BFDK12 - Som konsument ønsker jeg kontaktinformasjon til brukerstøtte for API slik at jeg kan få hjelp
API-katalogen BAM02 - Som ansvarlig for API-management ønsker jeg å dokumentere mitt API slik at utviklere raskt kan benytte API-et for tilgang til de data API-et representerer
API-katalogen Som utvikler i Altinn ønsker jeg å kunne registrere tredjepart API uten at API-eier har kjennskap til dette slik <hensikt>
API-katalogen Som utvikler i Altinn ønsker jeg å kunne registrere de API jeg utvikler for mine T.3 applikasjoner slik at <hensikt>
API-katalogen Som API-eier ønsker jeg å kunne beskrive funksjonaliteten i API-et på en overordnet måte slik at brukere får et innblikk i hva API-et innholder.
API-katalogen Som API-eier ønsker jeg å kunne beskrive et API som ikke nødvendigvis kan knyttes til et datasett, slik at også dynamiske tjenester kan synliggjøres for andre konsumenter.
API-katalogen Som API-eier ønsker jeg å angi at API’et skal være tilgjengelig i en runtime-tjenestekatalog (SMP/capability lookup) og Altinn tjenestekatalog/Authorization for samtykke og tilgangsstyring.
API-katalogen Som API-katalogeier ønsker jeg å kategorisere API-innslagene, slik at det kan differensieres mellom de.
API-katalogen Som ansvarlig for API-Management ønsker jeg en enkel måte å varsle endringer i oppetid
API-katalogen Som API-forvalter ønsker jeg en enkel måte å varsle endringer spesifikasjon av tjenester
API-katalogen Som API-forvalter/API-Management ansvarlig ønsker jeg en enkel måte å kommunisere informasjon rettet til enkeltbrukere av tjenester
API-katalogen Som API-forvalter/API-Management ansvarlig ønsker jeg en enkel måte å kommunisere sensitiv informasjon sikkert til (enkelt)brukere av tjenester
API-katalogen BAM09 - Som ansvarlig for API-management ønsker jeg å kunne administrere nøkler gitt til de enkelte konsumentene slik at jeg enkelt kan fjerne ev. misbruk av API-et
Mikrotjenesten/API-et Som sluttbruker ønsker jeg å gi samtykke til at en 3dje part kan innhente mine data fra offentlig myndighet slik at jeg slipper å tilgjengeliggjøre dataene selv
Mikrotjenesten/API-et Som sluttbruker ønsker jeg å gi samtykke til at en offentlig myndighet kan innhente mine data fra en 3dje part slik at jeg slipper å tilgjengegliggjøre dataene selv.
Mikrotjenesten/API-et Som sluttbruker ønsker jeg at en offentlig aktør skal ha tilgang til data om meg hos en annen offentlig aktør
Mikrotjenesten/API-et Som sluttbruker ønsker jeg at en privat virksomhet skal ha tilgang til data om meg fra en tredjepart (app) slik at jeg kan slippe å tiljgengeliggjøre dataene selv
Mikrotjenesten/API-et BFP004: Som profesjonell API-konsument ønsker jeg stabile API som beskytter meg mot endringer i underliggende data slik at jeg trenger ikke å oppdatere apiene mine ved dataendringer.
Mikrotjenesten/API-et BFP007: Som API-konsument ønsker jeg god og forutsigbar ytelse slik at det er lett å velge bruk av rett API som samsvarer med krav til andre API som inngår i tjenesten/prosessen
Mikrotjenesten/API-et BFP010: Som API-konsument ønsker jeg å bare lese endringer som er gjort på siste oppdatering slik at vi slipper å lese hele datasettet.
Mikrotjenesten/API-et BFP012: Som API-konsument ønsker jeg varsel på endringer (push-varsel og toveiskommunikasjon) slik at jeg kan forberede tiltak.
Mikrotjenesten/API-et BFP015: Som API-konsument ønsker jeg at nye versjoner av apiene blir gjort tilgjengelig før de settes i produksjon slik at jeg er forberedt.
Mikrotjenesten/API-et BFP018: Som API-konsument ønsker jeg at apiene inneholder referanser til lokale kodeverk som forklarer innholdet i apiene slik at jeg forstår detaljene i apiene.
Mikrotjenesten/API-et BFP019: Som API-konsument ønsker jeg at apiene inneholder referanser til begrepene som er brukt i apiene slik at jeg forstår detaljene og bruker dataene korrekt.
Mikrotjenesten/API-et BFP025: Som API-konsument ønsker jeg å se hvilke muligheter det finnes for konfigurasjon både hos meg og hos API-leverandør for å begrense tilgjengelig data til mitt faktiske formål. Kommentar: Dataminimering?
Mikrotjenesten/API-et BFP028: Som API-konsument ønsker jeg at API-et i større grad er “selvbeskrivende” og, dersom det brukes interne koder, at betydningen/forklaringen på disse er enkelt tilgjengelig, slik at jeg forstår hvordan jeg skal bruke API-et.
Mikrotjenesten/API-et BFP033: Som API-konsument ønsker jeg at API-et er avledet av en informasjonsmodell og Masterdata, som både sikrer konsistens mellom API og informasjonsmodell og gir mer og bedre dokumentasjon for API-et.
Mikrotjenesten/API-et BB1. Som API-konsument ønsker jeg et spørregrensesnitt (SQL-aktig/SPARQL/ODATA/GraphQL/NoSQL) mot API-et slik at jeg kan utforske datasettet og datasettets struktur/datamodell interaktivt som suplement til å lese dokumentasjon
Mikrotjenesten/API-et BB2. Som API-konsument ønsker jeg å gjøre spørringer og sammenstillinger og styre strukturen/formatet på resultatdatasettet selv, slik at jeg kan enkelt kan få det utsnittet av dataene som passer til den oppgaven jeg skal løse.
Mikrotjenesten/API-et BB3. Som API-konsument ønsker jeg å gjøre spørringer som gir meg dataene jeg har rettighet til å få (og ikke blir blokkert tilgang fordi API-et bare gir tilgang til mer data enn jeg har rettigheter til), slik at jeg kan få tilgang til data [rettigheter]
Mikrotjenesten/API-et BB4. Som API-konsument (ETL) ønsker jeg API-er som gir meg uttrekk som er tilpasset mine rettigheter og filtreringsbehov slik at jeg kan innhente uttrekket jeg trenger og har rett til. [rettigheter]
Mikrotjenesten/API-et BB12. Som API-konsument ønsker jeg at API-ene støtter de “connector”-teknologiene som brukes av mine foretrukne verktøy for sammenstilling, analyse og visualisering, f.eks. Tableau, slik at jeg slipper å lage en mellomløsning/laste ned datasett for å analysere dem [samhandlingsevne]
Mikrotjenesten/API-et BB21. Som API-konsument ønsker jeg å kunne laste ned endringer i et datasett jeg allerede har en lokal kopi av slik at jeg effektivt kan vaske eget register basert på samme datakilde. [varsel]
Mikrotjenesten/API-et BB24. Som API-konsument (ETL) ønsker, jeg stabile API-er som er uavhengige av underliggende data slik at jeg ikke trenger å følge med endringer i data formater/strukturer. [forutsigbarhet]
Mikrotjenesten/API-et BB25. Som API-konsument (ETL) ønsker jeg mulighet til å abonnere på endringsvarslinger om både data og API-versjoner slik at jeg kan oppfriske data og/eller utnytte nye datafelter. [varsel]
Mikrotjenesten/API-et BB27. Som API-konsument ønsker jeg å kunne laste ned en komplett versjon av datasettet i tillegg til API-funksjonalitet slik at jeg kan kjøre analyse på en lokal kopi av datasettet der dette er mest hensiktsmessig.[nedlasting]
Mikrotjenesten/API-et BB28. Som API-konsument ønsker jeg at API-et har god ytelse slik at jeg kan gjøre enkeltoppslag og ikke blir tvunget til å laste ned hele datasettet fordi API-et har lav ytelse. [tjenestenivå]
Mikrotjenesten/API-et BB29. Som API-konsument ønsker jeg en god mekanisme for å få beskjed om endringer i API eller dataformat (f.eks. ikke-brytende-endring som nye felt i dataformatet) slik at jeg kan tilpasse konsum av data når dataformatet blir endret eller utvidet.[varsel]
Mikrotjenesten/API-et BB30. Som API-konsument ønsker jeg å slippe å ha en kopi av xxregistreret eller datasettet slik at jeg kan være sikker på at dataene er oppdaterte. [tjenestenivå]
Mikrotjenesten/API-et BB31. Som API-konsument ønsker jeg at datasett som er gjort tilgjengelig for nedlasting har et forutsigbart URL-regime for siste versjon og historiske data slik at nedlasting kan automatiseres. [nedlasting, forutsigbarhet]
Mikrotjenesten/API-et BB32. Som API-konsument (datajournalist) ønsker jeg at strukturen i datasettene er stabile, slik at jeg ikke trenger gjøre endringer i min integrasjon/kode når nye versjoner hentes. [forutsigbarhet]
Mikrotjenesten/API-et BB33. Som API-konsument ønsker jeg å kunne laste ned kun endringer i et datasett for å oppdatere min lokale kopi av et datasett slik at jeg slipper å laste ned hele datasettet på nytt og import-jobben blir mindre. [varsel]
Mikrotjenesten/API-et BB34. Som API-konsument ønsker jeg å kunne se når hvilke deler av et datasett som er endret slik at jeg kan analysere endringer i data. [varsel]
Mikrotjenesten/API-et BB35. Som API-konsument ønsker jeg å kunne abonnere på hendelser slik at jeg får beskjed når hendelser oppstår. [varsel]
Mikrotjenesten/API-et BB36. Som API-konsument (ETL) ønsker jeg å unngå å laste komplette datasett og heller få de delene som har endret seg siden sist jeg lastet ned datasett slik at jeg minimerer egen ressursbruk. [varsel]
Mikrotjenesten/API-et BA7. Som API-konsument ønsker jeg selvforklarende API-er slik at jeg kan komme raskt i gang, få raskt nytte av API-et.
Mikrotjenesten/API-et BA9. Som API-konsument ønsker jeg at API-et er tilrettelagt for bruk, og ikke bare speiler innholdet i en database, slik at jeg kan slippe å forholde meg til et fagdomene, sette meg inn i interne kodeverk [brukerorientert, ikke avsenderstyrt …]
Mikrotjenesten/API-et BA11. Som API-konsument ønsker jeg at jeg kan bytte til nye versjoner av API-et når det passer meg [Kommentar frå Livar: Litt usikker på denne. Her er det kanskje snakk om versjonering av API, at ein sjølv kan velje når tid ein byttar til ny versjon av API? I motsetnad til at eit API ikkje er versjonert og ved "breaking-changes" så må ein forholde seg til når API-et gjer eit brått hopp til ny versjon?]
Mikrotjenesten/API-et BA13. Som API-konsument ønsker jeg at Tableau/R/etc kan hente inn data for meg slik at jeg kan lage visualiseringer uten å måtte vite noe om API-er.
Mikrotjenesten/API-et BA15. Som API-konsument ønsker jeg at alt jeg er avhengig av for applikasjonen min er tilgjengelig fra samme server, inklusive kodeverk, slik at CORS opprettholdes.
Mikrotjenesten/API-et BA16. Som API-konsument ønsker jeg at API-et tåler stor trafikk slik at jeg kan bruke API-et direkte i applikasjon
Mikrotjenesten/API-et BA19. Som API-konsument ønsker jeg API der kodeverk (f.eks. kommunenummer, næringskoder) er en del av API-responsen slik at jeg slipper å utføre flere API-kall og hente fra ulike kilder for å få data jeg trenger.
Mikrotjenesten/API-et BA21. Som API-konsument ønsker jeg et API som gir godt strukturerte responser slik at data er lett å bruke.
Mikrotjenesten/API-et BA24. Som API-konsument ønsker jeg, når jeg får en respons fra et datasett, en henvisning til arkiverte versjoner av “det samme” datasettet (med elementer som ikke lenger finnes i det løpende datasettet), slik at jeg kan gi en mer komplett respons til brukeren.
Mikrotjenesten/API-et BA26. Som API-konsument ønsker jeg at API-et støtter CORS slik at jeg kan nå det fra en webapplikasjon uten å måtte gå via egen backend eller proxy.
Mikrotjenesten/API-et BA33. Som API-konsument ønsker jeg at det er så få tekniske sperrer på API-ene som mulig slik at jeg kan ta det i bruk med minst mulig “prosess” mot API-forvalteren
Mikrotjenesten/API-et BA37. Som API-konsument ønsker jeg at tilgjengelige API-er er robuste slik at jeg kan anta at integrasjonen fungerer også ved høy trafikk
Mikrotjenesten/API-et BA38. Som API-konsument ønsker jeg (kanskje ....) HATEOAS og linked data-baserte API (for eks. JSON-LD/RDF-representasjoner) slik at jeg kan se hvilke opsjoner jeg har basert på de responsene jeg allerede har fått (den tilstanden jeg er i). [Kommentar frå Steinar: “basert på én informant ... han var tydelig på at han hadde gode erfaringer med API-er med RDF-data”]
Mikrotjenesten/API-et BA44. Som API-konsument ønsker jeg intelligente API-er som kan f.eks. filtrere, aggrerere, gruppere slik at jeg bare få inn de resultater jeg trenger av hensyn til personvern, kapasitet etc.
Mikrotjenesten/API-et BA45. Som API-konsument ønsker jeg et API med gode muligheter for å filtrere data slik at jeg kan hente ut akkurat det utsnittet av datasettet som jeg trenger til mitt formål og slipper å gjøre ekstra prosessering av responsen jeg får fra API-et.
Mikrotjenesten/API-et BA46. Som API-konsument ønsker jeg mulighet for å bruke filtre i API-et slik at jeg kan ha bedre kontroll med hvilket utvalg av data jeg mottar, og ikke er avhengig av hvilke utvalg API-forvalteren har definert.
Mikrotjenesten/API-et BA48. Som API-konsument ønsker jeg at API-ene jeg bruker tilbyr komplett nedlasting av datasett slik at jeg kan bearbeide data lokalt.
Mikrotjenesten/API-et BA49. Som API-konsument ønsker jeg ikke å tvinges til å bruke API-er der hvor det aller enkleste for meg ville vært å få lastet ned hele datasettet. [kommentar: ønskjer i alle fall anledning til å velje]
Mikrotjenesten/API-et BA53. Som API-konsument ønsker jeg at API-et støtter HTTP-standard med accept header for å velge data-format slik at kan gjøre det jeg er vant til.
Mikrotjenesten/API-et BA54. Som API-konsument ønsker jeg REST-API-er i tråd med REST-prinsippene/beste praksis slik at jeg kan bygge på erfaringene mine med andre REST-API-er, og forstå effekten av kallene i API-et med minst mulig teknisk dokumentasjon.
Mikrotjenesten/API-et 16. Som API-forvalter ønsker jeg å vite av hvem og hvor ofte mine API-er brukes (trafikkdata og bruksmønstre), slik at jeg optimere tilgang til API-er og ta stilling til hvilke API-er som eventuelt skal avvikles, samt kunne få grunnlag for å kunne rapportere på gevinstrealisering.
Mikrotjenesten/API-et 33. Som API-forvalter ønsker jeg at man tilbyr ei løsning/det blir spesifisert hvordan man skal tilby API på samme format.
Felles rammeverk Referansarkitektur
Felles rammeverk BTI003 Som innkjøper av fagsystemer ønsker jeg at Statens Standardavtaler inneholder krav til at leverandøren skal tilgjengeliggjøre API-er og data, slik at jeg får tilgang til og slipper å kjøpe tilbake mine egne data.
Felles rammeverk BTI008 Som konsument av data fra offentlige virksomheter ønsker jeg at de offentlige virksomhetene inngår avtaler med sine leverandører som gjør det tydelig hvem som eier dataene, og stiller krav til at de skal være gjøres tilgjengelige uten kostnader, slik at ikke den offentlige virksomheten hindres i å dele sine data med meg som følge av at kostnadene blir for store.
Felles rammeverk BTI009 Som konsument av offentlig data ønsker jeg en koordinert forvaltning av offentlig master data slik at jeg kan utvikle anvendelser/analyser med forutsigbar kvalitet og fornuftige økonomiske og juridiske betingelser.
Felles rammeverk BTI002 Som API-tilbyder som sammenstiller data på vegne av f.eks. kommuner ønsker jeg at de større systemene og registrene skal tilby API-er slik at jeg enkelt kan få tilgang til dataene for å gjennomføre mitt oppdrag.
Felles rammeverk BTI004 Som API-tilbyder ønsker jeg å tilby informasjon om mine API’er i henhold til en standard for å redusere mine forvaltningskostnader, for eksempel for å få redusert manuelle henvendelser
Felles rammeverk BTI011 Som API-tilbyder/privat grossist (som er databehandler for innrapportering og tilgjengeliggjøring av informasjon), ønsker jeg at det finnes et forum / nettverk der dataeiere og databrukere utarbeider gode krav til tilgjengeliggjøring og tilbakerapportering av aggregert informasjon.
Felles rammeverk BFP006: Som API-konsument ønsker jeg at det ikke er for rigide krav til dokumentering og til selve APIet slik at det ikke hemmer rask utvikling av API
Felles rammeverk BFP021: Som API-konsument ønsker jeg en standardisering av API-grensesnittene (inn og ut) slik at jeg kan ta i bruk nye datasett raskest mulig.
Felles rammeverk BFP024: Som API-konsument ønsker jeg i de tilfeller hvor API er basert på et lukket datasett å koble meg til et miljø med syntetisk data for bruk i utvikling og test.
Felles rammeverk BFP026: Som profesjonell API-konsument ønsker jeg forutsigbare økonomiske og juridiske rammer rundt (helst åpen/gratis) tilgang til offentlig data slik at jeg kan lage gode business cases.
Felles rammeverk BFP029: Som API-konsument ønsker jeg at offentlige dataeiere tilbyr APIer så tidlig som mulig (med tilsvarende varsling om datakvalitet) slik at jeg kan utvikle tjenester og bidra til kvalitetsforbedring av dataene.
Felles rammeverk BFP030: Som API-konsument ønsker jeg å kunne spørre produsent om mer og bedre data slik at vi kan tilby et bedre og mer helhetlig bilde.
Felles rammeverk BFP031: Som kommersiell API-konsument ønsker jeg at offentlige aktører ikke tilbyr konkurrerende verdiøkende tjenester på de API de tilbyr slik at jeg kan sikre min return on investment.
Felles rammeverk BFP033: Som API-konsument ønsker jeg at API-et er avledet av en informasjonsmodell og Masterdata, som både sikrer konsistens mellom API og informasjonsmodell og gir mer og bedre dokumentasjon for API-et.
Felles rammeverk BB1. Som API-konsument ønsker jeg et spørregrensesnitt (SQL-aktig/SPARQL/ODATA/GraphQL/NoSQL) mot API-et slik at jeg kan utforske datasettet og datasettets struktur/datamodell interaktivt som suplement til å lese dokumentasjon
Felles rammeverk BB3. Som API-konsument ønsker jeg å gjøre spørringer som gir meg dataene jeg har rettighet til å få (og ikke blir blokkert tilgang fordi API-et bare gir tilgang til mer data enn jeg har rettigheter til), slik at jeg kan få tilgang til data [rettigheter]
Felles rammeverk BB4. Som API-konsument (ETL) ønsker jeg API-er som gir meg uttrekk som er tilpasset mine rettigheter og filtreringsbehov slik at jeg kan innhente uttrekket jeg trenger og har rett til. [rettigheter]
Felles rammeverk BB12. Som API-konsument ønsker jeg at API-ene støtter de “connector”-teknologiene som brukes av mine foretrukne verktøy for sammenstilling, analyse og visualisering, f.eks. Tableau, slik at jeg slipper å lage en mellomløsning/laste ned datasett for å analysere dem [samhandlingsevne]
Felles rammeverk BB13. Som API-konsument ønsker jeg at de tjenestene offentlig sektor har utviklet på sine egne API gjøres tilgjengelig som åpen kildekode, slik at jeg kan gjenbruke relevante deler av koden for mitt eget konsum av API-et. [gjenbruk av kildekode]
Felles rammeverk BB14. Som API-konsument ønsker jeg standardavtaler for både vilkår for bruk av data og tjeneste slik at jeg vet hvilke vilkår og tjenestenivå jeg har å forholde meg til. [databehandleravtaler, SLA]
Felles rammeverk BB17. Som API-konsument ønsker jeg at spørringer, programkode og bibliotek som andre utvikler gjøres tilgjengelig som åpen kildekode slik at jeg kan dra nytte av disse i min prosess [gjenbruk av kildekode]
Felles rammeverk BB21. Som API-konsument ønsker jeg å kunne laste ned endringer i et datasett jeg allerede har en lokal kopi av slik at jeg effektivt kan vaske eget register basert på samme datakilde. [varsel]
Felles rammeverk BB22. Som API-konsument ønsker jeg å få dokumentasjonen fra samme sted som jeg henter ut data, slik at jeg vet at det er oppdatert og lett tilgjengelig. [dokumentasjon]
Felles rammeverk BB26. Som API-konsument ønsker jeg at API-ene jeg har tilgang til er de samme som API-forvalteren selv benytter til sin tjenesteutvikling, slik at jeg kan ha tillit til at forvaltning og videreutviklingen av API-ene gis prioritet og er verdt å bruke tid på å lære, gjøre bruk av [tjenestenivå/sla]
Felles rammeverk BB27. Som API-konsument ønsker jeg å kunne laste ned en komplett versjon av datasettet i tillegg til API-funksjonalitet slik at jeg kan kjøre analyse på en lokal kopi av datasettet der dette er mest hensiktsmessig.[nedlasting]
Felles rammeverk BB28. Som API-konsument ønsker jeg at API-et har god ytelse slik at jeg kan gjøre enkeltoppslag og ikke blir tvunget til å laste ned hele datasettet fordi API-et har lav ytelse. [tjenestenivå]
Felles rammeverk BB29. Som API-konsument ønsker jeg en god mekanisme for å få beskjed om endringer i API eller dataformat (f.eks. ikke-brytende-endring som nye felt i dataformatet) slik at jeg kan tilpasse konsum av data når dataformatet blir endret eller utvidet.[varsel]
Felles rammeverk BB30. Som API-konsument ønsker jeg å slippe å ha en kopi av xxregistreret eller datasettet slik at jeg kan være sikker på at dataene er oppdaterte. [tjenestenivå]
Felles rammeverk BB31. Som API-konsument ønsker jeg at datasett som er gjort tilgjengelig for nedlasting har et forutsigbart URL-regime for siste versjon og historiske data slik at nedlasting kan automatiseres. [nedlasting, forutsigbarhet]
Felles rammeverk BB32. Som API-konsument (datajournalist) ønsker jeg at strukturen i datasettene er stabile, slik at jeg ikke trenger gjøre endringer i min integrasjon/kode når nye versjoner hentes. [forutsigbarhet]
Felles rammeverk BB33. Som API-konsument ønsker jeg å kunne laste ned kun endringer i et datasett for å oppdatere min lokale kopi av et datasett slik at jeg slipper å laste ned hele datasettet på nytt og import-jobben blir mindre. [varsel]
Felles rammeverk BB34. Som API-konsument ønsker jeg å kunne se når hvilke deler av et datasett som er endret slik at jeg kan analysere endringer i data. [varsel]
Felles rammeverk BB36. Som API-konsument (ETL) ønsker jeg å unngå å laste komplette datasett og heller få de delene som har endret seg siden sist jeg lastet ned datasett slik at jeg minimerer egen ressursbruk. [varsel]
Felles rammeverk BA2. Som API-konsument ønsker jeg umiddelbar tilgang (slipper å vente på manuell tildeling av API-nøkler og tokens) til data (eller testdata) slik at jeg kan vurdere og eventuelt ta i bruk API-et umiddelbart.
Felles rammeverk BA7. Som API-konsument ønsker jeg selvforklarende API-er slik at jeg kan komme raskt i gang, få raskt nytte av API-et.
Felles rammeverk BA8. Som API-konsument ønsker jeg mulighet til enkelt å teste API-ene (utforske) f.eks. gjennom Swagger eller tilsvarende, slik at jeg raskere forstår API-et, og raskere klarer å bruke det (riktig) [ref BA7].
Felles rammeverk BA9. Som API-konsument ønsker jeg at API-et er tilrettelagt for bruk, og ikke bare speiler innholdet i en database, slik at jeg kan slippe å forholde meg til et fagdomene, sette meg inn i interne kodeverk [brukerorientert, ikke avsenderstyrt …]
Felles rammeverk BA11. Som API-konsument ønsker jeg at jeg kan bytte til nye versjoner av API-et når det passer meg [Kommentar frå Livar: Litt usikker på denne. Her er det kanskje snakk om versjonering av API, at ein sjølv kan velje når tid ein byttar til ny versjon av API? I motsetnad til at eit API ikkje er versjonert og ved "breaking-changes" så må ein forholde seg til når API-et gjer eit brått hopp til ny versjon?]
Felles rammeverk BA12. Som API-konsument ønsker jeg å hente inn data uavhengig av dataenes egentlig form slik at den ikke endrer seg når dataformatet endres.
Felles rammeverk BA13. Som API-konsument ønsker jeg at Tableau/R/etc kan hente inn data for meg slik at jeg kan lage visualiseringer uten å måtte vite noe om API-er.
Felles rammeverk BA15. Som API-konsument ønsker jeg at alt jeg er avhengig av for applikasjonen min er tilgjengelig fra samme server, inklusive kodeverk, slik at CORS opprettholdes.
Felles rammeverk BA16. Som API-konsument ønsker jeg at API-et tåler stor trafikk slik at jeg kan bruke API-et direkte i applikasjon
Felles rammeverk BA21. Som API-konsument ønsker jeg et API som gir godt strukturerte responser slik at data er lett å bruke.
Felles rammeverk BA24. Som API-konsument ønsker jeg, når jeg får en respons fra et datasett, en henvisning til arkiverte versjoner av “det samme” datasettet (med elementer som ikke lenger finnes i det løpende datasettet), slik at jeg kan gi en mer komplett respons til brukeren.
Felles rammeverk BA26. Som API-konsument ønsker jeg at API-et støtter CORS slik at jeg kan nå det fra en webapplikasjon uten å måtte gå via egen backend eller proxy.
Felles rammeverk BA27. Som API-konsument ønsker jeg at API-forvaltere lærer av webutviklere og tenker på brukerinvolvering og brukertesting slik at jeg kan få et API-som er lagt til rette for bruk
Felles rammeverk BA33. Som API-konsument ønsker jeg at det er så få tekniske sperrer på API-ene som mulig slik at jeg kan ta det i bruk med minst mulig “prosess” mot API-forvalteren
Felles rammeverk BA38. Som API-konsument ønsker jeg (kanskje ....) HATEOAS og linked data-baserte API (for eks. JSON-LD/RDF-representasjoner) slik at jeg kan se hvilke opsjoner jeg har basert på de responsene jeg allerede har fått (den tilstanden jeg er i). [Kommentar frå Steinar: “basert på én informant ... han var tydelig på at han hadde gode erfaringer med API-er med RDF-data”]
Felles rammeverk BA40. Som API-tilbyder* ønsker jeg retningslinjer og beste praksis for dokumentasjon av API-ene mine slik at jeg kan dokumentere så effektivt og bra som mulig.
Felles rammeverk BA44. Som API-konsument ønsker jeg intelligente API-er som kan f.eks. filtrere, aggrerere, gruppere slik at jeg bare få inn de resultater jeg trenger av hensyn til personvern, kapasitet etc.
Felles rammeverk BA45. Som API-konsument ønsker jeg et API med gode muligheter for å filtrere data slik at jeg kan hente ut akkurat det utsnittet av datasettet som jeg trenger til mitt formål og slipper å gjøre ekstra prosessering av responsen jeg får fra API-et.
Felles rammeverk BA46. Som API-konsument ønsker jeg mulighet for å bruke filtre i API-et slik at jeg kan ha bedre kontroll med hvilket utvalg av data jeg mottar, og ikke er avhengig av hvilke utvalg API-forvalteren har definert.
Felles rammeverk BA48. Som API-konsument ønsker jeg at API-ene jeg bruker tilbyr komplett nedlasting av datasett slik at jeg kan bearbeide data lokalt.
Felles rammeverk BA47. Som API-konsument ønsker jeg at API-ene jeg skal bruke er så like som mulig (men så forskjellige som nødvendig), slik at jeg ikke trenger sette meg inn i unødvendig mye nytt for hvert API jeg skal vurdere eller bruke.
Felles rammeverk BA53. Som API-konsument ønsker jeg at API-et støtter HTTP-standard med accept header for å velge data-format slik at kan gjøre det jeg er vant til.
Felles rammeverk BA54. Som API-konsument ønsker jeg REST-API-er i tråd med REST-prinsippene/beste praksis slik at jeg kan bygge på erfaringene mine med andre REST-API-er, og forstå effekten av kallene i API-et med minst mulig teknisk dokumentasjon.
Felles rammeverk BA55. Som API-konsument, ønsker jeg at API-et er designet etter en felles “beste praksis” som gjelder for API-er i API-katalogen, slik at jeg lett kjenner meg igjen på tvers av API-ene i katalogen.
Felles rammeverk 2. Som API-forvalter ønsker jeg at katalogen gir føringer for hvordan API-ene mine skal dokumenteres, etter “beste praksis”, så jeg slipper å sette meg inn i/holde meg oppdatert på hva som er beste praksis for API-dokumentasjon [frigjøre ressurser/bedre kvalitet]
Felles rammeverk 3. Som API-forvalter ønsker jeg at katalogen og dens underliggende spesifikasjoner og standarder gir krav jeg kan bruke i avtaler med leverandører/anskaffelser slik at jeg slipper å sette meg inn i hvilke krav jeg bør stille.
Felles rammeverk 4. Som API-forvalter ønsker jeg råd og forslag til avtaler med konsumenter slik at jeg kan gjøre flere API-er tilgjengelige for eksterne (f.eks. innovatører) og er trygg på å ha et godt avtaleverk og slipper å gjøre grunnarbeidet med vilkår og avtale for bruk.
Felles rammeverk 6. Som API-forvalter ønsker jeg at de aktivitetene jeg må gjøre og de standardene jeg må forholde meg til for å gjøre API-dokumentasjonen tilgjengelig i en nasjonal API-katalog, også gir verdi for andre, kommersielle, internasjonale API-kataloger, f.eks. synliggjøring på søkemotorer, ref Schema.orgs arbeid med vokabular for WebAPI http://pending.webschemas.org/WebAPI
Felles rammeverk 13. Som API-forvalter ønsker jeg å kunne påvirke utformingen av felles nasjonale oppskrifter for API-beskrivelser slik at de dekker mine behov.
Felles rammeverk 27. Som API-katalogeier ønsker jeg å koordinere beskrivelsene av API-ene som inngår i min katalog, slik at beskrivelsene fremstår som ensartet for de som skal benytte API-ene.
Felles rammeverk 33. Som API-forvalter ønsker jeg at man tilbyr ei løsning/det blir spesifisert hvordan man skal tilby API på samme format.
Felles rammeverk BAM02 - Som ansvarlig for API-management ønsker jeg å dokumentere mitt API slik at utviklere raskt kan benytte API-et for tilgang til de data API-et representerer
BAM07 - Som leverandør av API-management-verktøy ønsker jeg å kunne publisere dokumentasjon om API fra mitt API management verktøy til en felles offentlig API katalog API-management
BAM08 - Som ansvarlig for API-management ønsker jeg oversikt over brukerne av mitt API slik at jeg kan formidle endringer i APIet. [Livar: duplikat av BAM03?] API-management
BAM09 - Som ansvarlig for API-management ønsker jeg å kunne administrere nøkler gitt til de enkelte konsumentene slik at jeg enkelt kan fjerne ev. misbruk av API-et API-management
BAM10 - Som ansvarlig for API-management ønsker jeg ??? API-management
BAM11 - Som ansvarlig for API-management ønsker jeg å sikre eierskap av API-ene hos forretningseier/dataeier for å sikre kvalitet og eierskap. API-management
BAM12 - Som ansvarlig for API-management ønsker jeg et handlingsrom slik at jeg kan bestille endringer i datamodell/informasjonsmodell når behov/muligheter endrer seg. API-management
BAM13 - Som ansvarlig for API-management ønsker jeg at brukerne av mine API-er skal kunne gi innspill til endringer av mine API-er, slik at jeg gjøre API-ene mine mer brukervennlige. API-management
BAM15 - Som ansvarlig for API-management ønsker jeg å publisere informasjon om kostnader og trafikkbegrensninger for mine API-er, slik at potensielle brukere av mine API-er slipper å spørre meg om denne informasjonen API-management
BAM16 - Som ansvarlig for API-management ønsker jeg tydelige føringer på hvordan mitt API skal dokumenteres og gjøres tilgjengelig i en felles API-katalog slik at arbeidet kan planlegges, fordeles og operasjonaliseres i min virksomhet med et forutsigbart omfang. API-management
BAM16 - Som ansvarlig for API-management ønsker jeg tydelige føringer på hvordan mitt API skal dokumenteres og gjøres tilgjengelig i en felles API-katalog slik at arbeidet kan planlegges, fordeles og operasjonaliseres i min virksomhet med et forutsigbart omfang. Felles rammeverk
BAM17 - Som ansvarlig for API-management ønsker jeg at å tilby effektiv selvregistrering av brukere av API-ene, f.eks. gjennom autentisering via ID-porten/Altinn av dem som tar i bruk API-ene, slik at jeg senker terskelen for å ta API-et i bruk, samtidig som jeg beholder nødvendig oversikt over brukere. API-management
BAM18 - Som ansvarlig for flere datasett og medfølgende API’er ønsker jeg å ha kontroll på de datasettene forretningsenheten min tilbyr og enkelt gi tilgang til datasettene ved behov slik at jeg kan utføre ansvaret jeg har på en enkel måte API-management
API-konsumenter forvaltningen og proffesjonelle BFP002: Som API-konsument ønsker jeg enhetlig dokumentasjon og mulighet til “kundeservice” fra tjenesteleverandør.
API-konsumenter forvaltningen og proffesjonelle BFP003: Som API-konsument ønsker jeg å kunne se eventuelt tilknyttede informasjonsmodeller der det finnes, slik at jeg også kan finne og kvalitetssikre data og informasjon.
API-konsumenter forvaltningen og proffesjonelle BFP014: Som API-konsument ønsker jeg oversikt over tilgjengelige referanseimplementasjoner slik at jeg raskere kan komme i gang med å bruke apiene.
API-konsumenter forvaltningen og proffesjonelle BFP032: Som API-konsument ønsker jeg klar informasjon rundt lisensen på dataene APIet tilbyr for å raskt se om dette er forenlig med min bruk av dataene.
BFP001: Som API-forvalter ønsker jeg at det knyttes opplysninger om sikkerhetsvurderinger tilknyttet felt i API’et (identifiserende, lokaliserende, krav til sikring, osv.) slik at hensyn til innebygd personvern i større grad er ivaretatt for det datasettet som publiseres. API-konsumenter forvaltningen og proffesjonelle
BFP004: Som profesjonell API-konsument ønsker jeg stabile API som beskytter meg mot endringer i underliggende data slik at jeg trenger ikke å oppdatere apiene mine ved dataendringer. API-konsumenter forvaltningen og proffesjonelle
BFP005: Som API-konsument ønsker jeg at dokumentasjonen skal integreres i koden slik at den til enhver tid er oppdatert API-konsumenter forvaltningen og proffesjonelle
BFP006: Som API-konsument ønsker jeg at det ikke er for rigide krav til dokumentering og til selve APIet slik at det ikke hemmer rask utvikling av API API-konsumenter forvaltningen og proffesjonelle
BFP007: Som API-konsument ønsker jeg god og forutsigbar ytelse slik at det er lett å velge bruk av rett API som samsvarer med krav til andre API som inngår i tjenesten/prosessen API-konsumenter forvaltningen og proffesjonelle
BFP008: Som API-konsument ønsker jeg å vite oppdateringsfrekvens slik at jeg kan bestemme egen oppdatering. API-konsumenter forvaltningen og proffesjonelle
BFP009: Som API-konsument ønsker jeg å få dokumentere hvordan en kan oppdatere en egen kopi slik at en til hver tid bruker korrekte data. API-konsumenter forvaltningen og proffesjonelle
BFP011: Som API-konsument ønsker jeg et kontaktpunkt hos API-eier slik at man kan gi tilbakemelding og spørsmål. API-konsumenter forvaltningen og proffesjonelle
BFP010: Som API-konsument ønsker jeg å bare lese endringer som er gjort på siste oppdatering slik at vi slipper å lese hele datasettet. API-konsumenter forvaltningen og proffesjonelle
BFP012: Som API-konsument ønsker jeg varsel på endringer (push-varsel og toveiskommunikasjon) slik at jeg kan forberede tiltak. API-konsumenter forvaltningen og proffesjonelle
BFP013: Som API-konsument ønsker jeg en oversikt over tilgjengelige testmiljø for å teste ut apiene. API-konsumenter forvaltningen og proffesjonelle
BFP015: Som API-konsument ønsker jeg at nye versjoner av apiene blir gjort tilgjengelig før de settes i produksjon slik at jeg er forberedt. API-konsumenter forvaltningen og proffesjonelle
BFP016: Som API-konsument ønsker jeg en oversikt over hvilke versjoner som er tilgjengelig i hvilke miljø slik at jeg vet hva jeg kan teste mot. (prod og test) API-konsumenter forvaltningen og proffesjonelle
API-beskrivelsen BTI008 Som konsument av data fra offentlige virksomheter ønsker jeg at de offentlige virksomhetene inngår avtaler med sine leverandører som gjør det tydelig hvem som eier dataene, og stiller krav til at de skal være gjøres tilgjengelige uten kostnader, slik at ikke den offentlige virksomheten hindres i å dele sine data med meg som følge av at kostnadene blir for store.
API-beskrivelsen BTI010 Som API-tilbyder ønsker jeg å kunne se om andre tilbyr det samme eller nesten det samme som meg, så at det er mulig å harmonisere mellom “oss” [Livar: Case der det er fleire API-er som tilbyr det samme? Marit: Brreg og Skatt som har same datasett i FDK. Mathias: Felles studentsystem (FS) i UH-sektoren innheld personinformasjon. Kan ikkje konsoliderast med HR-data. Kan ikkje legge ned ein av dei. Dekker relasjonsfeltet i DCAT behovet?]
API-beskrivelsen Som sluttbruker ønsker jeg å gi samtykke til at en 3dje part kan innhente mine data fra offentlig myndighet slik at jeg slipper å tilgjengeliggjøre dataene selv
API-beskrivelsen Som sluttbruker ønsker jeg å gi samtykke til at en offentlig myndighet kan innhente mine data fra en 3dje part slik at jeg slipper å tilgjengegliggjøre dataene selv.
API-beskrivelsen Som sluttbruker ønsker jeg at en privat virksomhet skal ha tilgang til data om meg fra en tredjepart (app) slik at jeg kan slippe å tiljgengeliggjøre dataene selv
API-beskrivelsen Som sluttbruker ønsker jeg at en offentlig aktør skal ha tilgang til data om meg hos en annen offentlig aktør
API-beskrivelsen BAM02 - Som ansvarlig for API-management ønsker jeg å dokumentere mitt API slik at utviklere raskt kan benytte API-et for tilgang til de data API-et representerer
API-beskrivelsen BAM06 - Som ansvarlig for API-management ønsker jeg å kunne fordele eierskap og ansvar for de enkelte API-ene til det forretningsområdet som er dataforvalter/dataeier, slik at de kan være mest mulig selvbetjente og redusere flaskehalser (“publisher portal”)/sikre nærhet og dermed kvalitet (ansvarliggjøring av den rette aktøren)
API-beskrivelsen BAM09 - Som ansvarlig for API-management ønsker jeg å kunne administrere nøkler gitt til de enkelte konsumentene slik at jeg enkelt kan fjerne ev. misbruk av API-et
API-beskrivelsen BAM11 - Som ansvarlig for API-management ønsker jeg å sikre eierskap av API-ene hos forretningseier/dataeier for å sikre kvalitet og eierskap.
API-beskrivelsen BAM15 - Som ansvarlig for API-management ønsker jeg å publisere informasjon om kostnader og trafikkbegrensninger for mine API-er, slik at potensielle brukere av mine API-er slipper å spørre meg om denne informasjonen
API-beskrivelsen BAM18 - Som ansvarlig for flere datasett og medfølgende API’er ønsker jeg å ha kontroll på de datasettene forretningsenheten min tilbyr og enkelt gi tilgang til datasettene ved behov slik at jeg kan utføre ansvaret jeg har på en enkel måte
API-beskrivelsen BFP001: Som API-forvalter ønsker jeg at det knyttes opplysninger om sikkerhetsvurderinger tilknyttet felt i API’et (identifiserende, lokaliserende, krav til sikring, osv.) slik at hensyn til innebygd personvern i større grad er ivaretatt for det datasettet som publiseres.
API-beskrivelsen BFP002: Som API-konsument ønsker jeg enhetlig dokumentasjon og mulighet til “kundeservice” fra tjenesteleverandør.
API-beskrivelsen BFP003: Som API-konsument ønsker jeg å kunne se eventuelt tilknyttede informasjonsmodeller der det finnes, slik at jeg også kan finne og kvalitetssikre data og informasjon.
API-beskrivelsen BFP005: Som API-konsument ønsker jeg at dokumentasjonen skal integreres i koden slik at den til enhver tid er oppdatert
API-beskrivelsen BFP008: Som API-konsument ønsker jeg å vite oppdateringsfrekvens slik at jeg kan bestemme egen oppdatering.
API-beskrivelsen BFP009: Som API-konsument ønsker jeg å få dokumentere hvordan en kan oppdatere en egen kopi slik at en til hver tid bruker korrekte data.
API-beskrivelsen BFP011: Som API-konsument ønsker jeg et kontaktpunkt hos API-eier slik at man kan gi tilbakemelding og spørsmål.
API-beskrivelsen BFP013: Som API-konsument ønsker jeg en oversikt over tilgjengelige testmiljø for å teste ut apiene.
API-beskrivelsen BFP014: Som API-konsument ønsker jeg oversikt over tilgjengelige referanseimplementasjoner slik at jeg raskere kan komme i gang med å bruke apiene.
API-beskrivelsen BFP016: Som API-konsument ønsker jeg en oversikt over hvilke versjoner som er tilgjengelig i hvilke miljø slik at jeg vet hva jeg kan teste mot. (prod og test)
API-beskrivelsen BFP017: Som API-konsument ønsker jeg en endringslogg så tidlig som mulig slik at jeg vet hva som har endret seg mellom versjoner.
API-beskrivelsen BFP018: Som API-konsument ønsker jeg at apiene inneholder referanser til lokale kodeverk som forklarer innholdet i apiene slik at jeg forstår detaljene i apiene.
API-beskrivelsen BFP019: Som API-konsument ønsker jeg at apiene inneholder referanser til begrepene som er brukt i apiene slik at jeg forstår detaljene og bruker dataene korrekt.
API-beskrivelsen BFP020: Som API-konsument ønsker jeg informasjon om oppdateringsfrekvens av dataene eller om dataene er statiske.
API-beskrivelsen BFP022: Som API-konsument ønsker jeg eksempler/mal på bruk slik at jeg kan ta i bruk nye datasett raskest mulig.
API-beskrivelsen BFP023: Som API-konsument ønsker jeg å se hvilken SLA som er forbundet med API et slik at jeg kan vurdere om det tilfredsstiller mine krav for bruk.
API-beskrivelsen BFP024: Som API-konsument ønsker jeg i de tilfeller hvor API er basert på et lukket datasett å koble meg til et miljø med syntetisk data for bruk i utvikling og test.
API-beskrivelsen BFP025: Som API-konsument ønsker jeg å se hvilke muligheter det finnes for konfigurasjon både hos meg og hos API-leverandør for å begrense tilgjengelig data til mitt faktiske formål. Kommentar: Dataminimering?
API-beskrivelsen BFP026: Som profesjonell API-konsument ønsker jeg forutsigbare økonomiske og juridiske rammer rundt (helst åpen/gratis) tilgang til offentlig data slik at jeg kan lage gode business cases.
API-beskrivelsen BFP027: Som API-konsument ønsker jeg at dokumentasjonen til API-er jeg skal bruke har informasjon om kvalitet og tilgjengelighet, slik at jeg slipper mange henvendelser til API-tilbyder for å få svar på enkle ting.
API-beskrivelsen BFP030: Som API-konsument ønsker jeg å kunne spørre produsent om mer og bedre data slik at vi kan tilby et bedre og mer helhetlig bilde.
API-beskrivelsen BFP032: Som API-konsument ønsker jeg klar informasjon rundt lisensen på dataene APIet tilbyr for å raskt se om dette er forenlig med min bruk av dataene.
API-beskrivelsen BB5. Som API-konsument ønsker jeg å få tilgang til eksempler på bruk av API-et slik at jeg kan se mulighetene for bruk og bedre forstå hva API-et er ment å brukes til. [dokumentasjon]
API-beskrivelsen BB6. Som API-konsument ønsker jeg at semantikken rundt dataene er forklart (dataene er definert), slik at jeg kan ta et informert valg om å bruke dataene fordi jeg forstår kontekst, formål og omfanget av dem. [dokumentasjon]
API-beskrivelsen BB7. Som API-konsument ønsker jeg at det angis tydelig i dokumentasjonen hvilke data som er tilgjengelig, men også hva som ikke er tilgjengelig, slik at jeg slipper merarbeid pga. uklar dokumentasjon. [dokumentasjon]
API-beskrivelsen BB9. Som API-konsument (datajournalist) ønsker jeg å få forklaringer/dokumentasjon på hvordan dataene henger sammen slik at jeg kan spare tid på semantisk fortolkning (kobling mot datakatalogen?) [dokumentasjon]
API-beskrivelsen BB15. Som API-konsument ønsker jeg at relevante opplysninger som ikke er tilgjengelig i API-et er omtalt i dokumentasjonen, slik at jeg kan bruke API-et riktig. [dokumentasjon]
API-beskrivelsen BB16. Som API-konsument ønsker jeg at støttedatasett (f.eks. kodelister) er omtalt i dokumentasjonen slik at jeg kan anvende data fullt ut.[dokumentasjon]
API-beskrivelsen BB18. Som API-konsument ønsker jeg at kildekoden til API-tjenesten er tilgjengelig som åpen kildekode, slik at jeg kan lese kildekode for å forstå APIet og kunne bruke det optimalt [dokumentasjon]
API-beskrivelsen BA2. Som API-konsument ønsker jeg umiddelbar tilgang (slipper å vente på manuell tildeling av API-nøkler og tokens) til data (eller testdata) slik at jeg kan vurdere og eventuelt ta i bruk API-et umiddelbart.
API-beskrivelsen BA3. Som API-konsument ønsker jeg at det pekes til gode landingssider for API-et slik at jeg raskt settes i stand til å ta det i bruk.
API-beskrivelsen BA4. Som API-konsument ønsker jeg eksempler på API-requests slik at jeg kan komme fort i gang.
API-beskrivelsen BA5. Som API-konsument ønsker jeg at alle begreper linker direkte til en forklaring av begrepet slik at jeg slipper å lete gjennom dokumentasjonen. [kommentar: forskjell på begrep i den tekniske dokumentasjonen (f.eks. parameter i forespørsel) vs. begrep i datasettet (f.eks. fagtermer)]
API-beskrivelsen BA10.Som API-konsument ønsker jeg en indikasjon på hvor dynamisk datasettet er, slik at jeg har en idé om hvor ofte jeg trenger å lese data på nytt.
API-beskrivelsen BA14. Som API-konsument ønsker jeg lenker til applikasjoner som bruker datasettet, slik at jeg kan finne gode eksempler på bruk av API-et og datasettet. [kommentar: også programvarebibliotek og anna kodeverk som er relevant
API-beskrivelsen BA17. Som API-konsument ønsker jeg beskrivelse av API-et sin kapasitet slik at jeg vet om jeg trenger en egen server for sluttbrukerapplikasjoner ved svært høy trafikk.
API-beskrivelsen BA18. Som API-konsument ønsker jeg lenker til aktuelle kodeverk (f.eks. kommunenummer, næringskoder) slik at jeg lett kan hente støtte-datasett og dermed benytte datasettet fullt ut.
API-beskrivelsen BA22. Som API-konsument (app-utvikler) ønsker jeg en landingsside hvor jeg kan stille spørsmål om bruk av API-et slik at jeg kan bruke det mest mulig hensiktsmessig, og gjerne med henvisninger til kjent brukt av API-et.
API-beskrivelsen BA23. Som API-konsument (app-utvikler) ønsker jeg en landingsside hvor jeg får tilgang til FAQ om API-et. [Kommentar: manglar “slik at <forretningsverdi>”]
API-beskrivelsen BA28. Som API-konsument ønsker jeg informasjon om ytelsesmessige (svartid, antall oppslag) begrensninger i API-et, slik at jeg kan vurdere om API-et har god nok ytelse til mitt formål.
API-beskrivelsen BA29. Som API-konsument ønsker jeg informasjon om hvordan jeg kan skaffe meg tilgang til API-er som ikke er offentlig tilgjengelig. [Kommentar: manglar “slik at <forretningsverdi>”]
API-beskrivelsen BA30. Som API-konsument ønsker jeg informasjon om hvilke hjemler som gir tilgang til API-er der tilgangen er begrenset, slik at jeg kan vurdere om min virksomhet har lov til å benytte API-et til det aktuelle formålet.
API-beskrivelsen BA31. Som API-konsument ønsker jeg informasjon om eventuelle økonomiske betingelser for bruk av API-er, slik at jeg kan vurdere hvorvidt det er aktuelt å betale for bruk av API-et.
API-beskrivelsen BA32. Som API-konsument (gründer) ønsker jeg en tematisk oversikt over offentlige API slik at jeg kan lage nye tjenester.
API-beskrivelsen BA35. Som API-konsument ønsker jeg at det er tydelig hva som er de rettslige rammene for bruk av API-ene slik at jeg kan være sikker på at jeg ikke kan få krav mot meg senere, f.eks. NLOD.
API-beskrivelsen BA39. Som API-konsument ønsker jeg at begreper i API-ene er dokumentert slik at jeg forstår dokumentasjonen og bruker dataene i API-ene rett.
API-beskrivelsen BA40. Som API-tilbyder* ønsker jeg retningslinjer og beste praksis for dokumentasjon av API-ene mine slik at jeg kan dokumentere så effektivt og bra som mulig.
API-beskrivelsen BA41. Som API-konsument som benytter verktøy for å generere deler av kildekoden ønsker jeg at API-et er dokumentert iht “Open API Specification”, slik at jeg kan bruke kodegenereringsverktøy for å generere mye av den kildekoden som trengs for å bruke API-et fremfor å måtte skrive den selv [ref epost]
API-beskrivelsen BA43. Som API-konsument ønsker jeg å bli varslet om at et API er “deprecated” (skal tas ut av bruk), slik at jeg kan oppdatere min applikasjon.
API-beskrivelsen BA55. Som API-konsument, ønsker jeg at API-et er designet etter en felles “beste praksis” som gjelder for API-er i API-katalogen, slik at jeg lett kjenner meg igjen på tvers av API-ene i katalogen.
API-beskrivelsen 6. Som API-forvalter ønsker jeg at de aktivitetene jeg må gjøre og de standardene jeg må forholde meg til for å gjøre API-dokumentasjonen tilgjengelig i en nasjonal API-katalog, også gir verdi for andre, kommersielle, internasjonale API-kataloger, f.eks. synliggjøring på søkemotorer, ref Schema.orgs arbeid med vokabular for WebAPI http://pending.webschemas.org/WebAPI
API-beskrivelsen 8. Som API-forvalter som tilbyr data som ikke er åpne ønsker jeg å synliggjøre testmiljø for mine API-er slik at de er lette å oppdage for brukerne
API-beskrivelsen 11. Som API-forvalter/eier ønsker jeg å generere dokumentasjon ut fra koden eller tester, slik at jeg er sikker på at dokumentasjonen til enhver tid er oppdatert.
API-beskrivelsen 19. Som API-forvalter ønsker jeg kontaktinfo til de som bruker mine API slik at jeg kan ta kontakt med de om brukerundersøkelser, driftsmeldinger, endring av API, nye API og liknande. [dersom jeg ikke har egne løsninger for dette allerede]
API-beskrivelsen 27. Som API-katalogeier ønsker jeg å koordinere beskrivelsene av API-ene som inngår i min katalog, slik at beskrivelsene fremstår som ensartet for de som skal benytte API-ene.
API-beskrivelsen 35. Som API-katalogeier ønsker jeg å kategorisere API-innslagene, slik at det kan differensieres mellom de.
API-beskrivelsen BFDK13 - Som konsument av et åpent api ønsker jeg informasjon om hvor pålitelig leveransen av data er (forventet oppetid, responstid ved feil osb) slik at jeg kan gjøre en tilstrekkelig ROS-analyser for min integrasjon
API-beskrivelsen Som API-konsument ønsker jeg å vite hvilken interaksjonsform som tilbys i APIet (spørring, feed, fil) , slik at jeg kan vite om det dekker mine behov.
Referansarkitektur BTI001 Som innkjøper av fagsystemer trenger jeg et nettverk for å stille API-krav for tilgang til data slik at jeg kan trekke inn kompetanse til å spesifisere disse og få markedsmakt til å få leverandøren til å implementere dem.
Referansarkitektur BTI007 Som konsument av data fra kommunene ønsker jeg at kommunene tilbyr felles API for den samme informasjonen, uavhengig av hvilket fagsystem/hvilke leverandører de bruker for å forvalte informasjonen, slik at integrasjonen jeg utvikler mot én kommune kan gjenbrukes mot de resterende ca 400 kommunene.
Referansarkitektur BTI002 Som API-tilbyder som sammenstiller data på vegne av f.eks. kommuner ønsker jeg at de større systemene og registrene skal tilby API-er slik at jeg enkelt kan få tilgang til dataene for å gjennomføre mitt oppdrag.
Referansarkitektur BAM04 - Som leverandør av API-management-verktøy ønsker jeg at jeg å kunne tilby automatisk integrasjon med den felles API-katalogen slik at jeg kan selge mer av produktet mitt ved å vise til at det støtter opp under de nasjonale føringene.
Referansarkitektur BAM05 - Som leverandør av API-management-verktøy ønsker jeg at den felles API-katalogen støtter beste praksis for API-er og de mest utbredte standardene, slik at det blir lett for meg å integrere mitt verktøy med den felles API-katalogen [gjetter jeg på …]
Referansarkitektur BA34. Som API-konsument ønsker jeg at eventuelle krav til API-nøkler etc lar seg løse raskt/selvbetjent slik at jeg kan komme i gang raskt. [f.eks. autorisering basert på eksisterende mekanismer fremfor å måtte kontakte forvalter og vente på svar (ID-porten, Altinn), bruksvilkår fremfor avtaler]
En konkret tjeneste Mikrotjenesten/API-et
En konkret tjeneste BTI006 Som kommunal API-konsument ønsker jeg digital tilgang til kommunesektorens rapporteringskategorier (f.eks. om rapportering er periodisk, om den er hendelsesutløst, eventuell dato for søknadsfrister) slik at jeg kan sikre at alle tidsfrister kan holdes
BFP017: Som API-konsument ønsker jeg en endringslogg så tidlig som mulig slik at jeg vet hva som har endret seg mellom versjoner. API-konsumenter forvaltningen og proffesjonelle
BFP018: Som API-konsument ønsker jeg at apiene inneholder referanser til lokale kodeverk som forklarer innholdet i apiene slik at jeg forstår detaljene i apiene. API-konsumenter forvaltningen og proffesjonelle
BFP019: Som API-konsument ønsker jeg at apiene inneholder referanser til begrepene som er brukt i apiene slik at jeg forstår detaljene og bruker dataene korrekt. API-konsumenter forvaltningen og proffesjonelle
BFP020: Som API-konsument ønsker jeg informasjon om oppdateringsfrekvens av dataene eller om dataene er statiske. API-konsumenter forvaltningen og proffesjonelle
BFP021: Som API-konsument ønsker jeg en standardisering av API-grensesnittene (inn og ut) slik at jeg kan ta i bruk nye datasett raskest mulig. API-konsumenter forvaltningen og proffesjonelle
BFP022: Som API-konsument ønsker jeg eksempler/mal på bruk slik at jeg kan ta i bruk nye datasett raskest mulig. API-konsumenter forvaltningen og proffesjonelle
BFP023: Som API-konsument ønsker jeg å se hvilken SLA som er forbundet med API et slik at jeg kan vurdere om det tilfredsstiller mine krav for bruk. API-konsumenter forvaltningen og proffesjonelle
BFP024: Som API-konsument ønsker jeg i de tilfeller hvor API er basert på et lukket datasett å koble meg til et miljø med syntetisk data for bruk i utvikling og test. API-konsumenter forvaltningen og proffesjonelle
BFP025: Som API-konsument ønsker jeg å se hvilke muligheter det finnes for konfigurasjon både hos meg og hos API-leverandør for å begrense tilgjengelig data til mitt faktiske formål. Kommentar: Dataminimering? API-konsumenter forvaltningen og proffesjonelle
BFP026: Som profesjonell API-konsument ønsker jeg forutsigbare økonomiske og juridiske rammer rundt (helst åpen/gratis) tilgang til offentlig data slik at jeg kan lage gode business cases. API-konsumenter forvaltningen og proffesjonelle
BFP027: Som API-konsument ønsker jeg at dokumentasjonen til API-er jeg skal bruke har informasjon om kvalitet og tilgjengelighet, slik at jeg slipper mange henvendelser til API-tilbyder for å få svar på enkle ting. API-konsumenter forvaltningen og proffesjonelle
BFP028: Som API-konsument ønsker jeg at API-et i større grad er “selvbeskrivende” og, dersom det brukes interne koder, at betydningen/forklaringen på disse er enkelt tilgjengelig, slik at jeg forstår hvordan jeg skal bruke API-et. API-konsumenter forvaltningen og proffesjonelle
BFP029: Som API-konsument ønsker jeg at offentlige dataeiere tilbyr APIer så tidlig som mulig (med tilsvarende varsling om datakvalitet) slik at jeg kan utvikle tjenester og bidra til kvalitetsforbedring av dataene. API-konsumenter forvaltningen og proffesjonelle
BFP030: Som API-konsument ønsker jeg å kunne spørre produsent om mer og bedre data slik at vi kan tilby et bedre og mer helhetlig bilde. API-konsumenter forvaltningen og proffesjonelle
BFP031: Som kommersiell API-konsument ønsker jeg at offentlige aktører ikke tilbyr konkurrerende verdiøkende tjenester på de API de tilbyr slik at jeg kan sikre min return on investment. API-konsumenter forvaltningen og proffesjonelle
BFP033: Som API-konsument ønsker jeg at API-et er avledet av en informasjonsmodell og Masterdata, som både sikrer konsistens mellom API og informasjonsmodell og gir mer og bedre dokumentasjon for API-et. API-konsumenter forvaltningen og proffesjonelle
Åpne data statistikk, datajournalistikk og stordata BB16. Som API-konsument ønsker jeg at støttedatasett (f.eks. kodelister) er omtalt i dokumentasjonen slik at jeg kan anvende data fullt ut.[dokumentasjon]
Åpne data statistikk, datajournalistikk og stordata BB17. Som API-konsument ønsker jeg at spørringer, programkode og bibliotek som andre utvikler gjøres tilgjengelig som åpen kildekode slik at jeg kan dra nytte av disse i min prosess [gjenbruk av kildekode]
Åpne data statistikk, datajournalistikk og stordata BB18. Som API-konsument ønsker jeg at kildekoden til API-tjenesten er tilgjengelig som åpen kildekode, slik at jeg kan lese kildekode for å forstå APIet og kunne bruke det optimalt [dokumentasjon]
Åpne data statistikk, datajournalistikk og stordata BB19. Som API-konsument ønsker jeg å diskutere semantiske og tekniske spørsmål i en åpen kanal (wiki, github issues el liknende) for APIet jeg bruker, slik at brukerne kan hjelpe hverandre og tilbyder kan kommunisere åpent med sitt økosystem. [nettverk, dokumentasjon]
Åpne data statistikk, datajournalistikk og stordata BB20. Som API-konsument ønsker jeg eksempel på bruk av dataene som en del av dokumentasjonen av API-et, slik at de er enklere å fortså og ta i bruk [dokumentasjon]
BB1. Som API-konsument ønsker jeg et spørregrensesnitt (SQL-aktig/SPARQL/ODATA/GraphQL/NoSQL) mot API-et slik at jeg kan utforske datasettet og datasettets struktur/datamodell interaktivt som suplement til å lese dokumentasjon Åpne data statistikk, datajournalistikk og stordata
BB2. Som API-konsument ønsker jeg å gjøre spørringer og sammenstillinger og styre strukturen/formatet på resultatdatasettet selv, slik at jeg kan enkelt kan få det utsnittet av dataene som passer til den oppgaven jeg skal løse. Åpne data statistikk, datajournalistikk og stordata
BB3. Som API-konsument ønsker jeg å gjøre spørringer som gir meg dataene jeg har rettighet til å få (og ikke blir blokkert tilgang fordi API-et bare gir tilgang til mer data enn jeg har rettigheter til), slik at jeg kan få tilgang til data [rettigheter] Åpne data statistikk, datajournalistikk og stordata
BB4. Som API-konsument (ETL) ønsker jeg API-er som gir meg uttrekk som er tilpasset mine rettigheter og filtreringsbehov slik at jeg kan innhente uttrekket jeg trenger og har rett til. [rettigheter] Åpne data statistikk, datajournalistikk og stordata
BB5. Som API-konsument ønsker jeg å få tilgang til eksempler på bruk av API-et slik at jeg kan se mulighetene for bruk og bedre forstå hva API-et er ment å brukes til. [dokumentasjon] Åpne data statistikk, datajournalistikk og stordata
BB6. Som API-konsument ønsker jeg at semantikken rundt dataene er forklart (dataene er definert), slik at jeg kan ta et informert valg om å bruke dataene fordi jeg forstår kontekst, formål og omfanget av dem. [dokumentasjon] Åpne data statistikk, datajournalistikk og stordata
BB7. Som API-konsument ønsker jeg at det angis tydelig i dokumentasjonen hvilke data som er tilgjengelig, men også hva som ikke er tilgjengelig, slik at jeg slipper merarbeid pga. uklar dokumentasjon. [dokumentasjon] Åpne data statistikk, datajournalistikk og stordata
BB8. Som API-konsument ønsker jeg at utforskingsfasen/exploration/discovery gir meg rask oversikt og innsikt slik at jeg minimerer tiden jeg bruker på å velge et utsnitt eller må bruke egne verktøy for å skaffe meg oversikt. [dokumentasjon] Åpne data statistikk, datajournalistikk og stordata
BB9. Som API-konsument (datajournalist) ønsker jeg å få forklaringer/dokumentasjon på hvordan dataene henger sammen slik at jeg kan spare tid på semantisk fortolkning (kobling mot datakatalogen?) [dokumentasjon] Åpne data statistikk, datajournalistikk og stordata
BB10. Som API-konsument ønsker jeg mulighet til å innhente data om tekstdatasett slik at jeg kan lage analyser av disse og koble til andre kilde. [tekst som data] Åpne data statistikk, datajournalistikk og stordata
BB11. Som API-konsument (analytiker) ønsker jeg mulighet for å legg inn spørsmål, tips, eksempler knyttet til APIer slik at jeg kan øke min egen, andre brukere og api-forvalternes kjennskap om semantikk, selve APIen og bruk [økosystem] Åpne data statistikk, datajournalistikk og stordata
BB12. Som API-konsument ønsker jeg at API-ene støtter de “connector”-teknologiene som brukes av mine foretrukne verktøy for sammenstilling, analyse og visualisering, f.eks. Tableau, slik at jeg slipper å lage en mellomløsning/laste ned datasett for å analysere dem [samhandlingsevne] Åpne data statistikk, datajournalistikk og stordata
BB13. Som API-konsument ønsker jeg at de tjenestene offentlig sektor har utviklet på sine egne API gjøres tilgjengelig som åpen kildekode, slik at jeg kan gjenbruke relevante deler av koden for mitt eget konsum av API-et. [gjenbruk av kildekode] Åpne data statistikk, datajournalistikk og stordata
BB14. Som API-konsument ønsker jeg standardavtaler for både vilkår for bruk av data og tjeneste slik at jeg vet hvilke vilkår og tjenestenivå jeg har å forholde meg til. [databehandleravtaler, SLA] Åpne data statistikk, datajournalistikk og stordata
BB15. Som API-konsument ønsker jeg at relevante opplysninger som ikke er tilgjengelig i API-et er omtalt i dokumentasjonen, slik at jeg kan bruke API-et riktig. [dokumentasjon] Åpne data statistikk, datajournalistikk og stordata
BB21. Som API-konsument ønsker jeg å kunne laste ned endringer i et datasett jeg allerede har en lokal kopi av slik at jeg effektivt kan vaske eget register basert på samme datakilde. [varsel] Åpne data statistikk, datajournalistikk og stordata
BB22. Som API-konsument ønsker jeg å få dokumentasjonen fra samme sted som jeg henter ut data, slik at jeg vet at det er oppdatert og lett tilgjengelig. [dokumentasjon] Åpne data statistikk, datajournalistikk og stordata
BB23. Som API-konsument (stordata) ønsker jeg tilgang til tekster i maskinlesbart format og under en åpen lisens slik at jeg fritt kan bruke tekster i maskinanalyse av språk eller lignende.[tekst som data] Åpne data statistikk, datajournalistikk og stordata
BB24. Som API-konsument (ETL) ønsker, jeg stabile API-er som er uavhengige av underliggende data slik at jeg ikke trenger å følge med endringer i data formater/strukturer. [forutsigbarhet] Åpne data statistikk, datajournalistikk og stordata
BB25. Som API-konsument (ETL) ønsker jeg mulighet til å abonnere på endringsvarslinger om både data og API-versjoner slik at jeg kan oppfriske data og/eller utnytte nye datafelter. [varsel] Åpne data statistikk, datajournalistikk og stordata
BB26. Som API-konsument ønsker jeg at API-ene jeg har tilgang til er de samme som API-forvalteren selv benytter til sin tjenesteutvikling, slik at jeg kan ha tillit til at forvaltning og videreutviklingen av API-ene gis prioritet og er verdt å bruke tid på å lære, gjøre bruk av [tjenestenivå/sla] Åpne data statistikk, datajournalistikk og stordata
BB27. Som API-konsument ønsker jeg å kunne laste ned en komplett versjon av datasettet i tillegg til API-funksjonalitet slik at jeg kan kjøre analyse på en lokal kopi av datasettet der dette er mest hensiktsmessig.[nedlasting] Åpne data statistikk, datajournalistikk og stordata
BB28. Som API-konsument ønsker jeg at API-et har god ytelse slik at jeg kan gjøre enkeltoppslag og ikke blir tvunget til å laste ned hele datasettet fordi API-et har lav ytelse. [tjenestenivå] Åpne data statistikk, datajournalistikk og stordata
BB29. Som API-konsument ønsker jeg en god mekanisme for å få beskjed om endringer i API eller dataformat (f.eks. ikke-brytende-endring som nye felt i dataformatet) slik at jeg kan tilpasse konsum av data når dataformatet blir endret eller utvidet.[varsel] Åpne data statistikk, datajournalistikk og stordata
BB30. Som API-konsument ønsker jeg å slippe å ha en kopi av xxregistreret eller datasettet slik at jeg kan være sikker på at dataene er oppdaterte. [tjenestenivå] Åpne data statistikk, datajournalistikk og stordata
BB31. Som API-konsument ønsker jeg at datasett som er gjort tilgjengelig for nedlasting har et forutsigbart URL-regime for siste versjon og historiske data slik at nedlasting kan automatiseres. [nedlasting, forutsigbarhet] Åpne data statistikk, datajournalistikk og stordata
BB32. Som API-konsument (datajournalist) ønsker jeg at strukturen i datasettene er stabile, slik at jeg ikke trenger gjøre endringer i min integrasjon/kode når nye versjoner hentes. [forutsigbarhet] Åpne data statistikk, datajournalistikk og stordata
BB33. Som API-konsument ønsker jeg å kunne laste ned kun endringer i et datasett for å oppdatere min lokale kopi av et datasett slik at jeg slipper å laste ned hele datasettet på nytt og import-jobben blir mindre. [varsel] Åpne data statistikk, datajournalistikk og stordata
BB34. Som API-konsument ønsker jeg å kunne se når hvilke deler av et datasett som er endret slik at jeg kan analysere endringer i data. [varsel] Åpne data statistikk, datajournalistikk og stordata
BB35. Som API-konsument ønsker jeg å kunne abonnere på hendelser slik at jeg får beskjed når hendelser oppstår. [varsel] Åpne data statistikk, datajournalistikk og stordata
BB36. Som API-konsument (ETL) ønsker jeg å unngå å laste komplette datasett og heller få de delene som har endret seg siden sist jeg lastet ned datasett slik at jeg minimerer egen ressursbruk. [varsel] Åpne data statistikk, datajournalistikk og stordata
Studenter, gründere og app-utviklere BA23. Som API-konsument (app-utvikler) ønsker jeg en landingsside hvor jeg får tilgang til FAQ om API-et. [Kommentar: manglar “slik at <forretningsverdi>”]
Studenter, gründere og app-utviklere BA45. Som API-konsument ønsker jeg et API med gode muligheter for å filtrere data slik at jeg kan hente ut akkurat det utsnittet av datasettet som jeg trenger til mitt formål og slipper å gjøre ekstra prosessering av responsen jeg får fra API-et.
BA1. Som API-konsument (student) ønsker jeg å filtrere på dataformater i oversikter over (åpne) API-er slik at jeg kan finne API-er i det formatet jeg ønsker å lære mer om eller filtrere ut de jeg ikke kan noe om. Studenter, gründere og app-utviklere
BA2. Som API-konsument ønsker jeg umiddelbar tilgang (slipper å vente på manuell tildeling av API-nøkler og tokens) til data (eller testdata) slik at jeg kan vurdere og eventuelt ta i bruk API-et umiddelbart. Studenter, gründere og app-utviklere
BA3. Som API-konsument ønsker jeg at det pekes til gode landingssider for API-et slik at jeg raskt settes i stand til å ta det i bruk. Studenter, gründere og app-utviklere
BA4. Som API-konsument ønsker jeg eksempler på API-requests slik at jeg kan komme fort i gang. Studenter, gründere og app-utviklere
BA5. Som API-konsument ønsker jeg at alle begreper linker direkte til en forklaring av begrepet slik at jeg slipper å lete gjennom dokumentasjonen. [kommentar: forskjell på begrep i den tekniske dokumentasjonen (f.eks. parameter i forespørsel) vs. begrep i datasettet (f.eks. fagtermer)] Studenter, gründere og app-utviklere
BA7. Som API-konsument ønsker jeg selvforklarende API-er slik at jeg kan komme raskt i gang, få raskt nytte av API-et. Studenter, gründere og app-utviklere
BA8. Som API-konsument ønsker jeg mulighet til enkelt å teste API-ene (utforske) f.eks. gjennom Swagger eller tilsvarende, slik at jeg raskere forstår API-et, og raskere klarer å bruke det (riktig) [ref BA7]. Studenter, gründere og app-utviklere
BA9. Som API-konsument ønsker jeg at API-et er tilrettelagt for bruk, og ikke bare speiler innholdet i en database, slik at jeg kan slippe å forholde meg til et fagdomene, sette meg inn i interne kodeverk [brukerorientert, ikke avsenderstyrt …] Studenter, gründere og app-utviklere
BA10.Som API-konsument ønsker jeg en indikasjon på hvor dynamisk datasettet er, slik at jeg har en idé om hvor ofte jeg trenger å lese data på nytt. Studenter, gründere og app-utviklere
BA11. Som API-konsument ønsker jeg at jeg kan bytte til nye versjoner av API-et når det passer meg [Kommentar frå Livar: Litt usikker på denne. Her er det kanskje snakk om versjonering av API, at ein sjølv kan velje når tid ein byttar til ny versjon av API? I motsetnad til at eit API ikkje er versjonert og ved "breaking-changes" så må ein forholde seg til når API-et gjer eit brått hopp til ny versjon?] Studenter, gründere og app-utviklere
BA12. Som API-konsument ønsker jeg å hente inn data uavhengig av dataenes egentlig form slik at den ikke endrer seg når dataformatet endres. Studenter, gründere og app-utviklere
BA13. Som API-konsument ønsker jeg at Tableau/R/etc kan hente inn data for meg slik at jeg kan lage visualiseringer uten å måtte vite noe om API-er. Studenter, gründere og app-utviklere
BA14. Som API-konsument ønsker jeg lenker til applikasjoner som bruker datasettet, slik at jeg kan finne gode eksempler på bruk av API-et og datasettet. [kommentar: også programvarebibliotek og anna kodeverk som er relevant Studenter, gründere og app-utviklere
BA15. Som API-konsument ønsker jeg at alt jeg er avhengig av for applikasjonen min er tilgjengelig fra samme server, inklusive kodeverk, slik at CORS opprettholdes. Studenter, gründere og app-utviklere
BA16. Som API-konsument ønsker jeg at API-et tåler stor trafikk slik at jeg kan bruke API-et direkte i applikasjon Studenter, gründere og app-utviklere
BA17. Som API-konsument ønsker jeg beskrivelse av API-et sin kapasitet slik at jeg vet om jeg trenger en egen server for sluttbrukerapplikasjoner ved svært høy trafikk. Studenter, gründere og app-utviklere
BA18. Som API-konsument ønsker jeg lenker til aktuelle kodeverk (f.eks. kommunenummer, næringskoder) slik at jeg lett kan hente støtte-datasett og dermed benytte datasettet fullt ut. Studenter, gründere og app-utviklere
BA19. Som API-konsument ønsker jeg API der kodeverk (f.eks. kommunenummer, næringskoder) er en del av API-responsen slik at jeg slipper å utføre flere API-kall og hente fra ulike kilder for å få data jeg trenger. Studenter, gründere og app-utviklere
BA20. Som API-konsument ønsker jeg informasjon om hvor jeg kan finne statiske data som brukes til API-requests (Kommunenr, Kommunenavn..) slik at jeg slipper å lete etter dette selv. Studenter, gründere og app-utviklere
BA21. Som API-konsument ønsker jeg et API som gir godt strukturerte responser slik at data er lett å bruke. Studenter, gründere og app-utviklere
BA22. Som API-konsument (app-utvikler) ønsker jeg en landingsside hvor jeg kan stille spørsmål om bruk av API-et slik at jeg kan bruke det mest mulig hensiktsmessig, og gjerne med henvisninger til kjent brukt av API-et. Studenter, gründere og app-utviklere
BA24. Som API-konsument ønsker jeg, når jeg får en respons fra et datasett, en henvisning til arkiverte versjoner av “det samme” datasettet (med elementer som ikke lenger finnes i det løpende datasettet), slik at jeg kan gi en mer komplett respons til brukeren. Studenter, gründere og app-utviklere
BA25. Som API-konsument ønsker jeg at beskrivelser av API-er som ikke lengre er tilgjengelige, skal fjernes fra API-katalogen, slik at jeg slipper å lese om API-er som jeg uansett ikke kan bruke. Studenter, gründere og app-utviklere
BA26. Som API-konsument ønsker jeg at API-et støtter CORS slik at jeg kan nå det fra en webapplikasjon uten å måtte gå via egen backend eller proxy. Studenter, gründere og app-utviklere
BA27. Som API-konsument ønsker jeg at API-forvaltere lærer av webutviklere og tenker på brukerinvolvering og brukertesting slik at jeg kan få et API-som er lagt til rette for bruk Studenter, gründere og app-utviklere
BA28. Som API-konsument ønsker jeg informasjon om ytelsesmessige (svartid, antall oppslag) begrensninger i API-et, slik at jeg kan vurdere om API-et har god nok ytelse til mitt formål. Studenter, gründere og app-utviklere
BA29. Som API-konsument ønsker jeg informasjon om hvordan jeg kan skaffe meg tilgang til API-er som ikke er offentlig tilgjengelig. [Kommentar: manglar “slik at <forretningsverdi>”] Studenter, gründere og app-utviklere
BA30. Som API-konsument ønsker jeg informasjon om hvilke hjemler som gir tilgang til API-er der tilgangen er begrenset, slik at jeg kan vurdere om min virksomhet har lov til å benytte API-et til det aktuelle formålet. Studenter, gründere og app-utviklere
BA31. Som API-konsument ønsker jeg informasjon om eventuelle økonomiske betingelser for bruk av API-er, slik at jeg kan vurdere hvorvidt det er aktuelt å betale for bruk av API-et. Studenter, gründere og app-utviklere
BA32. Som API-konsument (gründer) ønsker jeg en tematisk oversikt over offentlige API slik at jeg kan lage nye tjenester. Studenter, gründere og app-utviklere
BA33. Som API-konsument ønsker jeg at det er så få tekniske sperrer på API-ene som mulig slik at jeg kan ta det i bruk med minst mulig “prosess” mot API-forvalteren Studenter, gründere og app-utviklere
BA34. Som API-konsument ønsker jeg at eventuelle krav til API-nøkler etc lar seg løse raskt/selvbetjent slik at jeg kan komme i gang raskt. [f.eks. autorisering basert på eksisterende mekanismer fremfor å måtte kontakte forvalter og vente på svar (ID-porten, Altinn), bruksvilkår fremfor avtaler] Studenter, gründere og app-utviklere
BA35. Som API-konsument ønsker jeg at det er tydelig hva som er de rettslige rammene for bruk av API-ene slik at jeg kan være sikker på at jeg ikke kan få krav mot meg senere, f.eks. NLOD. Studenter, gründere og app-utviklere
BA36. Som API-konsument ønsker jeg at noen tar jobben med å holde oversikt over om API-er er tilgjengelige, utilgjengelige, stabilt, deprecated etc slik at jeg slipper å begynne å ta det i bruk først før jeg oppdager det. Studenter, gründere og app-utviklere
BA37. Som API-konsument ønsker jeg at tilgjengelige API-er er robuste slik at jeg kan anta at integrasjonen fungerer også ved høy trafikk Studenter, gründere og app-utviklere
BA38. Som API-konsument ønsker jeg (kanskje ....) HATEOAS og linked data-baserte API (for eks. JSON-LD/RDF-representasjoner) slik at jeg kan se hvilke opsjoner jeg har basert på de responsene jeg allerede har fått (den tilstanden jeg er i). [Kommentar frå Steinar: “basert på én informant ... han var tydelig på at han hadde gode erfaringer med API-er med RDF-data”] Studenter, gründere og app-utviklere
BA39. Som API-konsument ønsker jeg at begreper i API-ene er dokumentert slik at jeg forstår dokumentasjonen og bruker dataene i API-ene rett. Studenter, gründere og app-utviklere
BA40. Som API-tilbyder* ønsker jeg retningslinjer og beste praksis for dokumentasjon av API-ene mine slik at jeg kan dokumentere så effektivt og bra som mulig. Studenter, gründere og app-utviklere
BA41. Som API-konsument som benytter verktøy for å generere deler av kildekoden ønsker jeg at API-et er dokumentert iht “Open API Specification”, slik at jeg kan bruke kodegenereringsverktøy for å generere mye av den kildekoden som trengs for å bruke API-et fremfor å måtte skrive den selv [ref epost] Studenter, gründere og app-utviklere
BA42. Som API-konsument ønsker jeg varsler om “breaking changes” slik at jeg kan gjøre de nødvendige endringene før de brekker mine systemer/applikasjoner også. [f.eks. ved registrere e-postadresse] Studenter, gründere og app-utviklere
BA43. Som API-konsument ønsker jeg å bli varslet om at et API er “deprecated” (skal tas ut av bruk), slik at jeg kan oppdatere min applikasjon. Studenter, gründere og app-utviklere
BA44. Som API-konsument ønsker jeg intelligente API-er som kan f.eks. filtrere, aggrerere, gruppere slik at jeg bare få inn de resultater jeg trenger av hensyn til personvern, kapasitet etc. Studenter, gründere og app-utviklere
BA46. Som API-konsument ønsker jeg mulighet for å bruke filtre i API-et slik at jeg kan ha bedre kontroll med hvilket utvalg av data jeg mottar, og ikke er avhengig av hvilke utvalg API-forvalteren har definert. Studenter, gründere og app-utviklere
BA48. Som API-konsument ønsker jeg at API-ene jeg bruker tilbyr komplett nedlasting av datasett slik at jeg kan bearbeide data lokalt. Studenter, gründere og app-utviklere
BA49. Som API-konsument ønsker jeg ikke å tvinges til å bruke API-er der hvor det aller enkleste for meg ville vært å få lastet ned hele datasettet. [kommentar: ønskjer i alle fall anledning til å velje] Studenter, gründere og app-utviklere
BA50. Som API-konsument, ønsker jeg å kunne gi tilbakemeldinger til god (eller dårlig) “beste praksis” for API-er, slik at dette kan være til hjelp for framtidige API-er som utvikles. Studenter, gründere og app-utviklere
BA51. Som API-konsument ønsker jeg mulighet til å gi tilbakemeldinger slik at jeg kan melde fra om feil eller foreslå forbedringer Studenter, gründere og app-utviklere
BA52. Som API-konsument ønsker jeg en enkel måte å rapportere inn feil i datakatalog (f.eks. Lenker som ikke fungerer) slik at jeg slipper å bla i utdatert innhold. Studenter, gründere og app-utviklere
BA6. Som API-konsument ønsker jeg å kunne på en enkel måte gi kontekstavhengige tilbakemeldinger til API-forvalteren, slik at dokumentasjonen og eller API-et blir bedre. Studenter, gründere og app-utviklere
BA47. Som API-konsument ønsker jeg at API-ene jeg skal bruke er så like som mulig (men så forskjellige som nødvendig), slik at jeg ikke trenger sette meg inn i unødvendig mye nytt for hvert API jeg skal vurdere eller bruke. Studenter, gründere og app-utviklere
BA53. Som API-konsument ønsker jeg at API-et støtter HTTP-standard med accept header for å velge data-format slik at kan gjøre det jeg er vant til. Studenter, gründere og app-utviklere
BA54. Som API-konsument ønsker jeg REST-API-er i tråd med REST-prinsippene/beste praksis slik at jeg kan bygge på erfaringene mine med andre REST-API-er, og forstå effekten av kallene i API-et med minst mulig teknisk dokumentasjon. Studenter, gründere og app-utviklere
BA55. Som API-konsument, ønsker jeg at API-et er designet etter en felles “beste praksis” som gjelder for API-er i API-katalogen, slik at jeg lett kjenner meg igjen på tvers av API-ene i katalogen. Studenter, gründere og app-utviklere
API-forvalter og API katalogeier 1.Som API-forvalter ønsker jeg at katalogen dekker informasjonsbehovet til de som skal benytte API-ene jeg forvalter, slik at jeg slipper å besvare henvendelser fra dem/redusere antall henvendelser [frigjøre ressurser]
API-forvalter og API katalogeier 2. Som API-forvalter ønsker jeg at katalogen gir føringer for hvordan API-ene mine skal dokumenteres, etter “beste praksis”, så jeg slipper å sette meg inn i/holde meg oppdatert på hva som er beste praksis for API-dokumentasjon [frigjøre ressurser/bedre kvalitet]
3. Som API-forvalter ønsker jeg at katalogen og dens underliggende spesifikasjoner og standarder gir krav jeg kan bruke i avtaler med leverandører/anskaffelser slik at jeg slipper å sette meg inn i hvilke krav jeg bør stille. API-forvalter og API katalogeier
4. Som API-forvalter ønsker jeg råd og forslag til avtaler med konsumenter slik at jeg kan gjøre flere API-er tilgjengelige for eksterne (f.eks. innovatører) og er trygg på å ha et godt avtaleverk og slipper å gjøre grunnarbeidet med vilkår og avtale for bruk. API-forvalter og API katalogeier
5. Som API-forvalter ønsker jeg at API-katalogen kan vise min Swagger-dokumentasjon slik at jeg bare kan eksponere for eksempel Swagger-data (YAML) og slipper å drifte min egen Swagger UI-nettside. [relatert til Swagger-brukerhistorien, trur eg] API-forvalter og API katalogeier
6. Som API-forvalter ønsker jeg at de aktivitetene jeg må gjøre og de standardene jeg må forholde meg til for å gjøre API-dokumentasjonen tilgjengelig i en nasjonal API-katalog, også gir verdi for andre, kommersielle, internasjonale API-kataloger, f.eks. synliggjøring på søkemotorer, ref Schema.orgs arbeid med vokabular for WebAPI http://pending.webschemas.org/WebAPI API-forvalter og API katalogeier
7. Som API-forvalter har jeg behov for å selv velge hvor selve dokumentasjonen skal ligge, slik at jeg kan bruke de verktøyene som er mest hensiktsmessig til formålet. API-forvalter og API katalogeier
8. Som API-forvalter som tilbyr data som ikke er åpne ønsker jeg å synliggjøre testmiljø for mine API-er slik at de er lette å oppdage for brukerne API-forvalter og API katalogeier
9. Som API-forvalter ønsker jeg en felles løsning for API-dokumentasjon som er så god at jeg selv ønsker å bruke løsningen fremfor andre verktøy API-forvalter og API katalogeier
10. Som en API-forvalter ønsker jeg å kunne ha “FAQ-funksjonalitet” (eller kunnskapsbase), slik at brukerne mine lettere kan få tak i svar på kjente utfordringer og jeg kan redusere kostnader ved å håndtere brukerhenvendelser. API-forvalter og API katalogeier
11. Som API-forvalter/eier ønsker jeg å generere dokumentasjon ut fra koden eller tester, slik at jeg er sikker på at dokumentasjonen til enhver tid er oppdatert. API-forvalter og API katalogeier
12. Som APi-forvalter/eier ønsker jeg at standarder og beskrivelser er helt maskinlesbare slik at høsting og bruk kan automatiseres og min rolle automatiseres bort eller erstattes av AI. API-forvalter og API katalogeier
13. Som API-forvalter ønsker jeg å kunne påvirke utformingen av felles nasjonale oppskrifter for API-beskrivelser slik at de dekker mine behov. API-forvalter og API katalogeier
14. Som API-forvalter/eier ønsker jeg en ensartet og samlet API-katalog slik at det blir enklere å publisere informasjonen. API-forvalter og API katalogeier
15. Som API-forvalter/eier ønsker jeg en ensartet og samlet beskrivelse av alle våre API-er slik at det er enkelt for brukerne å gjenbruke sin kunnskap om de skal bruke flere API-er. API-forvalter og API katalogeier
16. Som API-forvalter ønsker jeg å vite av hvem og hvor ofte mine API-er brukes (trafikkdata og bruksmønstre), slik at jeg optimere tilgang til API-er og ta stilling til hvilke API-er som eventuelt skal avvikles, samt kunne få grunnlag for å kunne rapportere på gevinstrealisering. API-forvalter og API katalogeier
17. Som API-forvalter ønsker jeg å vise frem eksempel på bruk av mine API-er slik at verdien av API-ene blir synliggjort og det kan inspirere flere til å bruke API-ene og hvordan bruke API-ene. API-forvalter og API katalogeier
18. Som API-forvalter ønsker jeg oversikt over integrasjoner mot mine API-er slik at konsekvenser og kostnader ved endringer kan forutses og minimeres. API-forvalter og API katalogeier
19. Som API-forvalter ønsker jeg kontaktinfo til de som bruker mine API slik at jeg kan ta kontakt med de om brukerundersøkelser, driftsmeldinger, endring av API, nye API og liknande. [dersom jeg ikke har egne løsninger for dette allerede] API-forvalter og API katalogeier
20. Som API-forvalter ønsker jeg at brukerne av mitt API skal ha en åpen kommunikasjon med meg og hverandre om hvilke behov de har som ikke er dekket i dag, slik at min videreutvikling treffer flest mulig brukere på en tilstrekkelig måte. API-forvalter og API katalogeier
21. Som API-forvalter ønsker jeg å få en effektiv kanal for å få tilbakemeldinger og behov fra de som bruker API-ene mine, slik at det blir lettere å prioritere riktig ved videreutvikling av API-ene [styrke dialog med brukerne av API-ene] API-forvalter og API katalogeier
22. Som en API-forvalter med allerede eksisterende API-katalog, ønsker jeg at løsningen er fleksibel(?)/legger til rette for automatisk høsting, slik at jeg kan vedlikeholde dokumentasjonen min lokalt. API-forvalter og API katalogeier
23. Som API-forvalter ønsker jeg at de API-ene jeg tilbyr skal være lette å finne og ta i bruk for de som har verdi av dem, slik at innsatsen jeg har lagt ned i API-ene får størst mulig verdi [forsvare kostnadene ved utviklingen/forvaltningen av API-ene/generere størst mulig nytte] API-forvalter og API katalogeier
24. Som API-forvalter (f.eks. av hotell.difi.no) ønsker jeg at API-ene er lette å finne og ta i bruk slik at verdien blir realisert. API-forvalter og API katalogeier
25. Som API-forvalter som forvalter API-er til autoritative data ønsker jeg at API-katalogen skal prioritere presentasjon av mine API-er fremfor API-er som tilbyr samme data, men fra ikke-autoritative kilder, slik at API-brukerne ikke ubevisst bruker ikke-autoritative data API-forvalter og API katalogeier
26. Som API-forvalter ønsker jeg at opplysninger som er relevante for datakatalogen og som finnes i API-et (feks “sist oppdatert”), høstes til datakatalogen slik at datasettbeskrivelsen er så god som mulig. API-forvalter og API katalogeier
27. Som API-katalogeier ønsker jeg å koordinere beskrivelsene av API-ene som inngår i min katalog, slik at beskrivelsene fremstår som ensartet for de som skal benytte API-ene. API-forvalter og API katalogeier
28. Som API-katalogeier ønsker jeg å, slik at jeg kan ha en total oversikt over API-ene våre kunne vite hvilke API-er min virksomhet tilbyr (og forvalte de på felles måte, vite hvem som bruker hvilke API-er osv.). API-forvalter og API katalogeier
29. Som API-katalogeier med en eksisterende API-dokumentasjon ønsker jeg å bruke eksisterende API-dokumentasjon slik at jeg slipper å vedlikeholde API-dokumentasjon (manuelt) flere steder. API-forvalter og API katalogeier
30. Som API-portaleier ønsker jeg at alle skal tilby sin informasjon på samme format, OG at alle har et eget API som beskriver sin katalog eller sitt API, slik at portalen enklest mulig kan høste og sammenstille informasjon om API-er. API-forvalter og API katalogeier
31. Som API-portaleier ønsker jeg å få inn statistikk fra API-forvaltere slik at vi kan få et overordnet oversikt for hele sektoren/landet. API-forvalter og API katalogeier
32. Som API-bruker ønsker jeg å registrere en anvendelse slik at jeg kan oppgi den i API-kallet. Alternativt: Som API-forvalter ønsker jeg at brukere kan registrere seg med en ID som de bruker i API-kallet slik at jeg kan koble trafikk og anvendelse. [f.eks. ved overbruk av API-et kan man lett kontakte den som har satt opp anvendelsen] API-forvalter og API katalogeier
33. Som API-forvalter ønsker jeg at man tilbyr ei løsning/det blir spesifisert hvordan man skal tilby API på samme format. API-forvalter og API katalogeier
34. Som API-katalogeier som ikke har en katalog, så ønsker jeg enkel måte å eksponere API-er på, ikke egen katalog med maskinlesbar beskrivelse, slik at jeg slipper å lage et eget verktøy med egne beskrivelser. API-forvalter og API katalogeier
35. Som API-katalogeier ønsker jeg å kategorisere API-innslagene, slik at det kan differensieres mellom de. API-forvalter og API katalogeier
FDK BFDK02 - Som forretningsutvikler ønsker jeg å søke etter API, slik at jeg raskt kan finne ut om det finnes data jeg kan gjenbruke
BFDK01 - Som forretningsutvikler ønsker jeg å se hvilke datasett som tilbyr API, slik at jeg kan vurdere om det kan brukes i mine tjenester. FDK
BFDK03 - Som forretningsutvikler ønsker jeg å se detaljerte beskrivelser av APIene, slik at jeg kan vurdere om de er av tilstrekkelig kvalitet for bruk i mine tjenester FDK
BFDK04 - Som forretningsutvikler ønsker jeg å filtrere på datasett som har API, slik at jeg bedre treff på mine søk i katalogen. FDK
BFDK05 - Som forretningsutvikler ønsker jeg å kunne sammenligne APIere, slik at jeg vurdere om et API passer bedre enn et annet for min bruk. FDK
BFDK06 - Som arkitekt ønsker jeg å se hvilke data jeg må benytte for å gjøre oppslag mot et API og hvilke data jeg får tilbake slik at jeg kan planlegge design av løsning. FDK
BFDK07 - Som datasetteier (og som beskriver datasett i datakatalogen) ønsker jeg å kunne kople beskrivelser av APIer (i flertall) til et gitt datasett, slik at jeg kan vise hvilke distribusjoner som finnes av et datasett FDK
BFDK08 - Som datasetteier (som beskriver datasett i datakatalogen) ønsker jeg å kunne plukke fra API-beskrivelsen dataelementene som jeg ønsker å ta med i datasettbeskrivelsen, slik at dataelementene jeg tar med gjenspeiler det som APIet virkelig kan tilby. FDK
BFDK09 - Som datasetteier for historiske (avleverte) data ønsker jeg å kunne koble de historiske datasettene med tilsvarende aktive/nåværende datasett, slik at jeg kan tilby brukerne en helhetlig tilgang til dataene. FDK
BFDK10 - Som konsument ønsker jeg å få en liste over de datasett jeg vil ha tilgang til, presentert med grunnleggende informasjon om API slik at jeg sammenligne egenskaper (for eksempel hvilken protokoll som er brukt) ved API-ene FDK
BFDK11 - Som konsument ønsker jeg å abonnere på varslinger om etablering, endring, driftsstans og avvikling av API’er slik at jeg kan tilpasse meg endringer FDK
BFDK12 - Som konsument ønsker jeg kontaktinformasjon til brukerstøtte for API slik at jeg kan få hjelp FDK
BFDK13 - Som konsument av et åpent api ønsker jeg informasjon om hvor pålitelig leveransen av data er (forventet oppetid, responstid ved feil osb) slik at jeg kan gjøre en tilstrekkelig ROS-analyser for min integrasjon FDK
API-mangement verktøyleverandør BAM01 - Som ansvarlig for API-management ønsker jeg å publisere mine API i en API-katalog slik at utviklere raskt kan finne frem til mitt API/økt synlighet
API-mangement verktøyleverandør BAM02 - Som ansvarlig for API-management ønsker jeg å dokumentere mitt API slik at utviklere raskt kan benytte API-et for tilgang til de data API-et representerer
API-mangement verktøyleverandør BAM03 - Som ansvarlig for API-management ønsker jeg å notifisere endringer i mine API til dem som benytter API-ene slik at man ikke bryter kontrakter
API-mangement verktøyleverandør BAM04 - Som leverandør av API-management-verktøy ønsker jeg at jeg å kunne tilby automatisk integrasjon med den felles API-katalogen slik at jeg kan selge mer av produktet mitt ved å vise til at det støtter opp under de nasjonale føringene.
API-mangement verktøyleverandør BAM05 - Som leverandør av API-management-verktøy ønsker jeg at den felles API-katalogen støtter beste praksis for API-er og de mest utbredte standardene, slik at det blir lett for meg å integrere mitt verktøy med den felles API-katalogen [gjetter jeg på …]
API-mangement verktøyleverandør BAM06 - Som ansvarlig for API-management ønsker jeg å kunne fordele eierskap og ansvar for de enkelte API-ene til det forretningsområdet som er dataforvalter/dataeier, slik at de kan være mest mulig selvbetjente og redusere flaskehalser (“publisher portal”)/sikre nærhet og dermed kvalitet (ansvarliggjøring av den rette aktøren)
API-mangement verktøyleverandør BAM07 - Som leverandør av API-management-verktøy ønsker jeg å kunne publisere dokumentasjon om API fra mitt API management verktøy til en felles offentlig API katalog
API-mangement verktøyleverandør BAM08 - Som ansvarlig for API-management ønsker jeg oversikt over brukerne av mitt API slik at jeg kan formidle endringer i APIet. [Livar: duplikat av BAM03?]
API-mangement verktøyleverandør BAM09 - Som ansvarlig for API-management ønsker jeg å kunne administrere nøkler gitt til de enkelte konsumentene slik at jeg enkelt kan fjerne ev. misbruk av API-et
API-mangement verktøyleverandør BAM11 - Som ansvarlig for API-management ønsker jeg å sikre eierskap av API-ene hos forretningseier/dataeier for å sikre kvalitet og eierskap.
API-mangement verktøyleverandør BAM13 - Som ansvarlig for API-management ønsker jeg at brukerne av mine API-er skal kunne gi innspill til endringer av mine API-er, slik at jeg gjøre API-ene mine mer brukervennlige.
API-mangement verktøyleverandør BAM15 - Som ansvarlig for API-management ønsker jeg å publisere informasjon om kostnader og trafikkbegrensninger for mine API-er, slik at potensielle brukere av mine API-er slipper å spørre meg om denne informasjonen
API-mangement verktøyleverandør BAM16 - Som ansvarlig for API-management ønsker jeg tydelige føringer på hvordan mitt API skal dokumenteres og gjøres tilgjengelig i en felles API-katalog slik at arbeidet kan planlegges, fordeles og operasjonaliseres i min virksomhet med et forutsigbart omfang.
API-mangement verktøyleverandør BAM17 - Som ansvarlig for API-management ønsker jeg at å tilby effektiv selvregistrering av brukere av API-ene, f.eks. gjennom autentisering via ID-porten/Altinn av dem som tar i bruk API-ene, slik at jeg senker terskelen for å ta API-et i bruk, samtidig som jeg beholder nødvendig oversikt over brukere.
Dataeier BAM18 - Som ansvarlig for flere datasett og medfølgende API’er ønsker jeg å ha kontroll på de datasettene forretningsenheten min tilbyr og enkelt gi tilgang til datasettene ved behov slik at jeg kan utføre ansvaret jeg har på en enkel måte
Dataeier BFDK07 - Som datasetteier (og som beskriver datasett i datakatalogen) ønsker jeg å kunne kople beskrivelser av APIer (i flertall) til et gitt datasett, slik at jeg kan vise hvilke distribusjoner som finnes av et datasett
Dataeier BFDK08 - Som datasetteier (som beskriver datasett i datakatalogen) ønsker jeg å kunne plukke fra API-beskrivelsen dataelementene som jeg ønsker å ta med i datasettbeskrivelsen, slik at dataelementene jeg tar med gjenspeiler det som APIet virkelig kan tilby.
Dataeier BFDK09 - Som datasetteier for historiske (avleverte) data ønsker jeg å kunne koble de historiske datasettene med tilsvarende aktive/nåværende datasett, slik at jeg kan tilby brukerne en helhetlig tilgang til dataene.
Forretningsutvikler BFDK01 - Som forretningsutvikler ønsker jeg å se hvilke datasett som tilbyr API, slik at jeg kan vurdere om det kan brukes i mine tjenester.
Forretningsutvikler BFDK02 - Som forretningsutvikler ønsker jeg å søke etter API, slik at jeg raskt kan finne ut om det finnes data jeg kan gjenbruke
Forretningsutvikler BFDK03 - Som forretningsutvikler ønsker jeg å se detaljerte beskrivelser av APIene, slik at jeg kan vurdere om de er av tilstrekkelig kvalitet for bruk i mine tjenester
Forretningsutvikler BFDK04 - Som forretningsutvikler ønsker jeg å filtrere på datasett som har API, slik at jeg bedre treff på mine søk i katalogen.
Forretningsutvikler BFDK05 - Som forretningsutvikler ønsker jeg å kunne sammenligne APIere, slik at jeg vurdere om et API passer bedre enn et annet for min bruk.
Altinn Som utvikler i Altinn ønsker jeg å kunne registrere tredjepart API uten at API-eier har kjennskap til dette slik <hensikt>
Altinn Som utvikler i Altinn ønsker jeg å kunne registrere de API jeg utvikler for mine T.3 applikasjoner slik at <hensikt>
Som API-eier ønsker jeg å kunne beskrive funksjonaliteten i API-et på en overordnet måte slik at brukere får et innblikk i hva API-et innholder. Informasjonsforvaltning fagmiljø
Som API-eier ønsker jeg å kunne beskrive et API som ikke nødvendigvis kan knyttes til et datasett, slik at også dynamiske tjenester kan synliggjøres for andre konsumenter. Informasjonsforvaltning fagmiljø
Som API-eier ønsker jeg å angi at API’et skal være tilgjengelig i en runtime-tjenestekatalog (SMP/capability lookup) og Altinn tjenestekatalog/Authorization for samtykke og tilgangsstyring. Informasjonsforvaltning fagmiljø
Som API-konsument ønsker jeg å vite hvilken interaksjonsform som tilbys i APIet (spørring, feed, fil) , slik at jeg kan vite om det dekker mine behov. Informasjonsforvaltning fagmiljø
Som API-katalogeier ønsker jeg å kategorisere API-innslagene, slik at det kan differensieres mellom de. Informasjonsforvaltning fagmiljø
Skatteetaten Som API-forvalter ønsker jeg en enkel måte å varsle endringer spesifikasjon av tjenester
Skatteetaten Som ansvarlig for API-Management ønsker jeg en enkel måte å varsle endringer i oppetid
Skatteetaten Som API-forvalter/API-Management ansvarlig ønsker jeg en enkel måte å kommunisere informasjon rettet til enkeltbrukere av tjenester
Skatteetaten Som API-forvalter/API-Management ansvarlig ønsker jeg en enkel måte å kommunisere sensitiv informasjon sikkert til (enkelt)brukere av tjenester
Skatteetaten Som API-konsument ønsker jeg standardiserte autentiserings- og autoriseringsmekanismer som kan gjenbrukes for flere tjenester
Skatteetaten Som API-konsument ønsker jeg single sign on (SSO) mellom flere tjenester jeg benytter slik at jeg unngår separat autentisering mot hver enkelt tjeneste
Skatteetaten Som API-konsument ønsker jeg at nasjonal/delt infrastruktur tilbyr felles mønstre for autentisering og autorisering mot API slik at jeg slipper å bestille og forvalte tilgangsstyring hos hver enkelt tjenestetilbyder.
Skatteetaten Som API-forvalter/API-management ansvarlig ønsker jeg en nasjonal/delt infrastruktur for administrasjon og utstedelse av tilgangstokens for API-konsumenter slik at jeg slipper å utstede og forvalte disse selv (dette gjelder både hjemmelsbasert og samtykkebasert tilgang).
Skatteetaten Som API-forvalter ønsker jeg at definerte APIer i API-katalogen kan overføres til felleskomponenter for tilgangsstyring og autentisering slik at jeg slipper å registrere disse dobbelt (og dermed risikere feil i registreringer)
Skatteetaten Som API-forvalter ønsker jeg å kunne få overført mine API-definisjoner til en runtime tjenestekatalog (SMP, CapabiliityLookup eller den tekniske endepunktedelen av KoFuVi?) for å kunne legge til metadata for runtime-kall slik at jeg ikke må registrere mine API-definisjoner dobbelt.
Som API-forvalter/ansvarlig for API-management ønsker jeg en enkel måte å kommunisere livssyklus planer og garantier for en tjeneste (f.eks. nedleggelse/utfasing) slik at jeg kan avvikle tjenester når det er ønskelig Skatteetaten
Som potensiell API-konsument ønsker jeg å kjenne til livssyklus planer og garantier for en tjeneste (f.eks. nedleggelse/utfasing) slik at jeg ikke gjør meg avhengig av eksterne APIer som kan forsvinne Skatteetaten
Som API-konsument ønsker jeg å kunne gi strukturerte tilbakemeldinger (f.eks. feil) og endringsforslag for tjenester slik at tjenestene kan forbedres Skatteetaten
Som API-forvalter ønsker jeg å kunne motta strukturerte tilbakemeldinger (f.eks. feil) og endringsforslag for mine tjenester slik at tjenestene kan forbedres Skatteetaten
Difi konseptutredning "deling av data" Det er behov for enkel tilgang til data av god kvalitet, og som er beskrevet på en standardisert måte
Datakonsumenter har behov for tilgang til dataene på en enkel og standardisert måte. Difi konseptutredning "deling av data"
Datakonsumenter har behov for et ryddig avtaleregime for tilgang til dataene. Difi konseptutredning "deling av data"