Hva er den raskeste måten å komme i gang på?

Den nøkkelløse sandkassen. Den svarer med produksjonens responsformer fra syntetiske testdata uten nøkkel, sertifikat eller konto, så du kan ha en fungerende klient samme ettermiddag som du bestemmer deg for å bygge en. Få dataformen riktig der, bytt så inn en nøkkel og fjern sandkasse-prefikset fra stien.

Hvor mye kan jeg bygge før jeg har legitimasjon?

Hele klienten, pluss de delene av produktet ditt som bruker den. Sandkassen er deterministisk, så du kan skrive reelle tester mot den framfor tester som tåler variasjon, og den injiserer de fire vanlige feiltilfellene på forespørsel slik at feilhåndteringen din blir prøvd. Det du ikke kan, er å bevise noe om en reell rundtur til det offentlige.

Hva endrer seg egentlig fra sandkassen til produksjon?

Sti-prefikset og én header. Responsformene er de samme med hensikt, og det er poenget med å speile dem. Det som endrer seg under, er at dataene er reelle, at hastighetsgrenser gjelder per nøkkel framfor per IP, og at selskapsinterne fakta krever kundens delegering framfor å ligge i et testdatasett.

Trenger jeg nøkkel til alt?

Nei. Endepunkter for offentlig infrastruktur, verktøylistene og funksjonsmanifestet er nøkkelløse med hensikt og forblir det, fordi de finnes for oppdagelse framfor inntekt. Alt om et navngitt selskap krever nøkkel også på gratisnivået, siden de dataene grenser til personopplysninger: styremedlemmer, signaturrett, innsendingsatferd.

Når bør jeg heller bygge integrasjonen selv?

Når du trenger en etat eller en tjeneste som ikke er meglet, når du er et offentlig organ med et tjenesteeierforhold som gir deg tilgang en kommersiell integratør ikke kan ha, eller når integrasjonen er produktet ditt framfor en avhengighet i det. I det siste tilfellet er sertifikatlivsløpet og skjemakoblingen det du selger, så det å eie dem er hele poenget.

Hva er den raskeste måten å bygge programvare som fungerer med norske offentlige tjenester?

Start mot den nøkkelløse sandkassen, få dataformen riktig, og bytt så inn en nøkkel. Grunnen til at denne rekkefølgen vinner er ikke at sandkassen er smart, men at oppsettsarbeidet er den lange stangen: sertifikater, bruksvilkår og registreringer beveger seg på andre organisasjoners kalendere, mens klientkoden tar noen dager. Bygg den delen som tar dager først, og la den som tar måneder løpe parallelt. Når legitimasjonen kommer, endrer du et sti-prefiks og legger til én header.

Det interessante tallet under hvert trinn er ikke hva det gjør, men hva det koster å komme inn i. To av de tre er ting du kan gjøre i dag, og det tredje er det eneste som trenger noen andre.

Hva kan jeg bygge før noen legitimasjon finnes?

I praksis hele klienten. Den offentlige sandkassen speiler produksjonens responsformer fra syntetiske norske testdata og krever ingenting i det hele tatt: ingen nøkkel, intet sertifikat, ingen konto, ingen delegering. Du kan skrive forespørselslaget, tolkningen, domenemodellen du kobler svarene mot, og de delene av produktet ditt som viser resultatet, før noen har signert noe.

To egenskaper gjør at den tiden er godt brukt framfor bortkastet. Sandkassen er deterministisk, så samme forespørsel gir samme kropp og du kan skrive vanlige assertions i stedet for tester som tåler variasjon. Og den injiserer feiltilfeller på forespørsel: en simulate_error-parameter gir svarene for manglende delegering, ugyldig token, validering og manglende scope, i samme strukturerte form som produksjon bruker. Feilhåndtering skrevet mot de svarene er feilhåndtering som virker.

Den ærlige grensen er at ingenting av det beviser noe om en reell rundtur til det offentlige, fordi sandkassen aldri kaller et offentlig system på noe verb. Den sier at klienten din er riktig. Den sier ikke at en innsending ville gått gjennom. Se den som verktøyet for å få formen riktig, som er det mesteparten av kalenderen går med til uansett.

Hva er korteste vei til et reelt kall?

Noen kall er allerede reelle og krever ingenting. Pliktmalen for en organisasjonsform, den løpende fristkalenderen, funksjonsmanifestet og verktøylistene er alle nøkkelløse med hensikt og svarer mot live data. Trenger produktet ditt å vite hva et norsk aksjeselskap må sende inn, er du ferdig: ingen konto, ingen nøkkel, ingen venting.

For alt om et navngitt selskap er korteste vei en nøkkel. Fjern sandbox/public-prefikset fra stien du allerede har kalt, og legg til en Authorization: Bearer-header. Det gir deg det åpne registernivået for enhver organisasjon: hva den er, om den er aktiv, hvem som kan signere for den, de publiserte regnskapene, og pliktevalueringen disse faktaene gir. Intet sertifikat er involvert på din side, fordi den offentlige legitimasjonskjeden ligger bak kallet framfor i koden din.

Det siste trinnet er det ingen kan forkorte. Selskapsinterne fakta krever det selskapets delegering, som er en beslutning bare selskapet kan ta. Det du kan styre, er hvor enkelt du gjør det: be om et smalt sett rettigheter, forklar hva hver enkelt er til, og sjekk tildelingen før hver handling framfor å anta at den varer. Se veiledningen om delegering til systembruker for hva kunden faktisk ser.

Når er det riktig å bygge det selv?

Oftere enn en leverandørside vanligvis innrømmer. Det klareste tilfellet er dekning: trenger du en etat, en tjeneste eller et datasett som ikke er meglet, kan en megler ikke hjelpe deg, og å legge til en er en avhengighet uten tilsvarende gevinst. Sjekk funksjonslisten mot dine faktiske krav før du bestemmer deg, framfor mot formen på kravene slik du forestiller deg dem.

Det andre tilfellet er hvem du er. Offentlige etater har tilgangsveier som er stengt for kommersielle integratører, og har du et tjenesteeierforhold, bør du bruke det framfor å gå rundt det via en tredjepart. Det tredje tilfellet er det ærlige: er integrasjonen produktet ditt framfor en avhengighet i det, er sertifikatlivsløpet, skjemakoblingen og delegeringsflyten det du selger. Å sette dem ut betyr å sette ut det som gjør produktet ditt til ditt.

Der en megler gjør nytte for seg, er i mellomtilfellet: du trenger norske etterlevelsesdata for å få et annet produkt til å virke, integrasjonen er ikke det som skiller deg fra andre, og kostnaden du unngår er ikke den første byggingen, men den løpende. Fornyelse av sertifikater, nøkkelrotasjon, drift i skjemaer oppstrøms og håndtering av delegeringer slutter ikke ved lansering, og den gjentakende belastningen er den ærlige sammenligningen framfor den første sprinten.

Gjør det første kallet

Disse to er den samme forespørselen på to trinn. Legg merke til hvor lite som endrer seg mellom dem, og det er egenskapen som gjør det verdt å starte i sandkassen framfor å se det som en omvei.

# Trinn én. Ingen nøkkel, sertifikat, delegering eller konto.
curl -s https://www.apier.no/api/v1/sandbox/public/company/999999999/summary

// Trinn to: samme sti uten sandkasse-prefikset, pluss en nøkkel.
const res = await fetch(
  "https://www.apier.no/api/v1/company/999999999/summary",
  { headers: { Authorization: `Bearer ${process.env.APIER_API_KEY}` } },
);

const { data, _meta } = await res.json();
console.log(data.name, _meta.rulebook_version, _meta.data_freshness);

Ofte stilte spørsmål

Hva er den raskeste måten å komme i gang på?: Den nøkkelløse sandkassen. Den svarer med produksjonens responsformer fra syntetiske testdata uten nøkkel, sertifikat eller konto, så du kan ha en fungerende klient samme ettermiddag som du bestemmer deg for å bygge en. Få dataformen riktig der, bytt så inn en nøkkel og fjern sandkasse-prefikset fra stien.
Hvor mye kan jeg bygge før jeg har legitimasjon?: Hele klienten, pluss de delene av produktet ditt som bruker den. Sandkassen er deterministisk, så du kan skrive reelle tester mot den framfor tester som tåler variasjon, og den injiserer de fire vanlige feiltilfellene på forespørsel slik at feilhåndteringen din blir prøvd. Det du ikke kan, er å bevise noe om en reell rundtur til det offentlige.
Hva endrer seg egentlig fra sandkassen til produksjon?: Sti-prefikset og én header. Responsformene er de samme med hensikt, og det er poenget med å speile dem. Det som endrer seg under, er at dataene er reelle, at hastighetsgrenser gjelder per nøkkel framfor per IP, og at selskapsinterne fakta krever kundens delegering framfor å ligge i et testdatasett.
Trenger jeg nøkkel til alt?: Nei. Endepunkter for offentlig infrastruktur, verktøylistene og funksjonsmanifestet er nøkkelløse med hensikt og forblir det, fordi de finnes for oppdagelse framfor inntekt. Alt om et navngitt selskap krever nøkkel også på gratisnivået, siden de dataene grenser til personopplysninger: styremedlemmer, signaturrett, innsendingsatferd.
Når bør jeg heller bygge integrasjonen selv?: Når du trenger en etat eller en tjeneste som ikke er meglet, når du er et offentlig organ med et tjenesteeierforhold som gir deg tilgang en kommersiell integratør ikke kan ha, eller når integrasjonen er produktet ditt framfor en avhengighet i det. I det siste tilfellet er sertifikatlivsløpet og skjemakoblingen det du selger, så det å eie dem er hele poenget.