Brukerhistorier Felles rammeverk

Brukerhistorier Felles rammeverk ()


Felles rammeverk
Premissgiver - styring dokumentasjon av API-er
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.
13. Som API-forvalter ønsker jeg å kunne påvirke utformingen av felles nasjonale oppskrifter for API-beskrivelser slik at de dekker mine behov.
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.
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]
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.
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]
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.
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.
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
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
Veiledning - Beste praksis - dokumentasjon av API-er
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.
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.
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.
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]
Nettverk (faglig forum)
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
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.
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.
Standardisering - Grensesnitt API/mikrotjeneste
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.
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.
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.
BA7. Som API-konsument ønsker jeg selvforklarende API-er slik at jeg kan komme raskt i gang, få raskt nytte av 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]
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].
Veiledning - Beste praksis - API/mikrotjeneste
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.
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.
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.
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]
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]
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 …]
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.
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.
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]
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.
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]
BA48. Som API-konsument ønsker jeg at API-ene jeg bruker tilbyr komplett nedlasting av datasett slik at jeg kan bearbeide data lokalt.
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]
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]
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”]
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.
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
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
BA12. Som API-konsument ønsker jeg å hente inn data uavhengig av dataenes egentlig form slik at den ikke endrer seg når dataformatet endres.
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]
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.
33. Som API-forvalter ønsker jeg at man tilbyr ei løsning/det blir spesifisert hvordan man skal tilby API på samme format.
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]
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]
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]
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.
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]
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]
Standardisering - API beskrivelser
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
Premissgiver - Tilgjengelighetskrav API-er til grunndata
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.
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å]
Sikkerhetsarkitektur - API/mikrotjeneste
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.
Orden i eget hus - beskrivelse av API
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.
Personvern - API/mikrotjeneste
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]
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.
Premissgiver - Kvalitetskrav til API/mikrotjeneste
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.
BA21. Som API-konsument ønsker jeg et API som gir godt strukturerte responser slik at data er lett å bruke.
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?]
Premissgiver - Ytelseskrav til API/mikrotjeneste
BA16. Som API-konsument ønsker jeg at API-et tåler stor trafikk slik at jeg kan bruke API-et direkte i applikasjon
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å]
Premissgiver - Tjenesteutvikling på API/mikrotjenester
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.
Premissgiver - Betaling på API/mikrotjenester
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.
Referansarkitektur


		Felles rammeverk	Personvern - API/mikrotjeneste
		Felles rammeverk	Orden i eget hus - beskrivelse av API
		Felles rammeverk	Sikkerhetsarkitektur - API/mikrotjeneste
		Felles rammeverk	Premissgiver - Tilgjengelighetskrav API-er til grunndata
		Felles rammeverk	Standardisering - API beskrivelser
		Felles rammeverk	Veiledning - Beste praksis - API/mikrotjeneste
		Felles rammeverk	Premissgiver - Kvalitetskrav til API/mikrotjeneste
		Felles rammeverk	Standardisering - Grensesnitt API/mikrotjeneste
		Felles rammeverk	Premissgiver - Ytelseskrav til API/mikrotjeneste
		Felles rammeverk	Nettverk (faglig forum)
		Felles rammeverk	Veiledning - Beste praksis - dokumentasjon av API-er
		Felles rammeverk	Premissgiver - styring dokumentasjon av API-er
		Felles rammeverk	Referansarkitektur
		Felles rammeverk	Premissgiver - Tjenesteutvikling på API/mikrotjenester
		Felles rammeverk	Premissgiver - Betaling på API/mikrotjenester
		Premissgiver - styring dokumentasjon av API-er	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
		Premissgiver - styring dokumentasjon av API-er	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
		Premissgiver - styring dokumentasjon av API-er	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.
		Premissgiver - styring dokumentasjon av API-er	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.
		Premissgiver - styring dokumentasjon av API-er	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]
		Premissgiver - styring dokumentasjon av API-er	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.
		Premissgiver - styring dokumentasjon av API-er	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]
		Premissgiver - styring dokumentasjon av API-er	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.
		Premissgiver - styring dokumentasjon av API-er	13. Som API-forvalter ønsker jeg å kunne påvirke utformingen av felles nasjonale oppskrifter for API-beskrivelser slik at de dekker mine behov.
		Premissgiver - styring dokumentasjon av API-er	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.
		Veiledning - Beste praksis - dokumentasjon av API-er	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.
		Veiledning - Beste praksis - dokumentasjon av API-er	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.
		Veiledning - Beste praksis - dokumentasjon av API-er	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.
		Veiledning - Beste praksis - dokumentasjon av API-er	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]
		Nettverk (faglig forum)	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.
		Nettverk (faglig forum)	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
		Nettverk (faglig forum)	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.
		Standardisering - Grensesnitt API/mikrotjeneste	BA7. Som API-konsument ønsker jeg selvforklarende API-er slik at jeg kan komme raskt i gang, få raskt nytte av API-et.
		Standardisering - Grensesnitt API/mikrotjeneste	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.
		Standardisering - Grensesnitt API/mikrotjeneste	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.
		Standardisering - Grensesnitt API/mikrotjeneste	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.
		Standardisering - Grensesnitt API/mikrotjeneste	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]
		Standardisering - Grensesnitt API/mikrotjeneste	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].
		Veiledning - Beste praksis - API/mikrotjeneste	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]
		Veiledning - Beste praksis - API/mikrotjeneste	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]
		Veiledning - Beste praksis - API/mikrotjeneste	BA48. Som API-konsument ønsker jeg at API-ene jeg bruker tilbyr komplett nedlasting av datasett slik at jeg kan bearbeide data lokalt.
		Veiledning - Beste praksis - API/mikrotjeneste	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]
		Veiledning - Beste praksis - API/mikrotjeneste	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.
		Veiledning - Beste praksis - API/mikrotjeneste	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]
		Veiledning - Beste praksis - API/mikrotjeneste	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.
		Veiledning - Beste praksis - API/mikrotjeneste	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.
		Veiledning - Beste praksis - API/mikrotjeneste	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 …]
		Veiledning - Beste praksis - API/mikrotjeneste	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]
		Veiledning - Beste praksis - API/mikrotjeneste	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]
		Veiledning - Beste praksis - API/mikrotjeneste	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.
		Veiledning - Beste praksis - API/mikrotjeneste	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.
		Veiledning - Beste praksis - API/mikrotjeneste	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.
		Veiledning - Beste praksis - API/mikrotjeneste	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”]
		Veiledning - Beste praksis - API/mikrotjeneste	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.
		Veiledning - Beste praksis - API/mikrotjeneste	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
		Veiledning - Beste praksis - API/mikrotjeneste	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
		Veiledning - Beste praksis - API/mikrotjeneste	BA12. Som API-konsument ønsker jeg å hente inn data uavhengig av dataenes egentlig form slik at den ikke endrer seg når dataformatet endres.
		Veiledning - Beste praksis - API/mikrotjeneste	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]
		Veiledning - Beste praksis - API/mikrotjeneste	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.
		Veiledning - Beste praksis - API/mikrotjeneste	33. Som API-forvalter ønsker jeg at man tilbyr ei løsning/det blir spesifisert hvordan man skal tilby API på samme format.
		Veiledning - Beste praksis - API/mikrotjeneste	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]
		Veiledning - Beste praksis - API/mikrotjeneste	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]
		Veiledning - Beste praksis - API/mikrotjeneste	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]
		Veiledning - Beste praksis - API/mikrotjeneste	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.
		Veiledning - Beste praksis - API/mikrotjeneste	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]
		Veiledning - Beste praksis - API/mikrotjeneste	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]
		Standardisering - API beskrivelser	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
		Premissgiver - Tilgjengelighetskrav API-er til grunndata	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.
		Premissgiver - Tilgjengelighetskrav API-er til grunndata	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å]
		Sikkerhetsarkitektur - API/mikrotjeneste	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.
		Orden i eget hus - beskrivelse av API	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.
		Personvern - API/mikrotjeneste	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]
		Personvern - API/mikrotjeneste	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.
		Premissgiver - Kvalitetskrav til API/mikrotjeneste	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?]
		Premissgiver - Kvalitetskrav til API/mikrotjeneste	BA21. Som API-konsument ønsker jeg et API som gir godt strukturerte responser slik at data er lett å bruke.
		Premissgiver - Kvalitetskrav til API/mikrotjeneste	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.
		Premissgiver - Ytelseskrav til API/mikrotjeneste	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å]
		Premissgiver - Ytelseskrav til API/mikrotjeneste	BA16. Som API-konsument ønsker jeg at API-et tåler stor trafikk slik at jeg kan bruke API-et direkte i applikasjon
		Premissgiver - Tjenesteutvikling på API/mikrotjenester	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.
		Premissgiver - Betaling på API/mikrotjenester	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.