Et API åbnes for partnere: hvornår skal det testes?

Et API, der hidtil kun er brugt internt, skifter karakter, når partnere får adgang. Nye parter, nye nøgler og nye data krydser grænsen. Hvornår det skal testes, hviler på ét spørgsmål: hvornår er API’et og adgangsstyringen færdige nok til, at testen afprøver det, partnerne faktisk får?

Testen bør ligge, efter at API’et, partneradgangen og dokumentationen er på plads, men før den første partner kobler på med rigtige data. Så kan fund rettes uden at skulle forhandles med partnere, der allerede er afhængige af API’et.

Antagelser, der ikke holder længere

Internt kan et API leve med antagelser: at kun egne systemer kalder det, og at de opfører sig pænt. Når partnere får adgang, holder de antagelser ikke længere. En partners system kan have fejl, en nøgle kan komme i forkerte hænder, og en partner kan forsøge at hente mere end aftalt. Partnerne er heller ikke ens. En stor forhandler med egen IT-afdeling og en lille forhandler med et standardsystem håndterer adgangen til API’et forskelligt, og API’et skal kunne tåle begge.

I et tænkt eksempel åbner virksomheden ERP-systemets ordre-API for en række forhandlere, så de selv kan se lagerstatus og afgive ordrer. Før talte API’et kun med webshoppen. Nu skal det kunne skelne forhandlerne fra hinanden, så den ene ikke ser den andens priser, rabatter og ordrer. → Kunders oplysninger skal holdes adskilt

Ændringen sker ofte gradvist. Først får en enkelt partner adgang som et forsøg, så kommer der flere, og pludselig er API’et en del af forretningen, uden at nogen har besluttet, at det nu skal behandles som en løsning, der vender mod omverdenen.

Hvor i forløbet hører testen til?

Et API-projekt til partnere har typisk en udviklingsfase, en pilot med en enkelt partner og en bred åbning. Testen kan placeres flere steder.

Før piloten · API’et kan testes i et miljø, der svarer til driften, og der er ingen partnere at tage hensyn til.
Før den brede åbning · erfaringerne fra piloten er med, og fund kan rettes, før flere kobler på.
Efter åbningen · testen afprøver det, partnerne bruger, men rettelser kan kræve koordinering med dem.

Den første eller anden placering giver mest plads til at rette. En test efter åbningen er relevant, når API’et udvides med nye funktioner, nye datatyper eller nye partnertyper.

Læg også testen i forhold til partneraftalerne. Hvis aftalen med partnerne lover en bestemt dato, skal testen og rettelserne kunne nås inden. Ellers ender testen med at blive presset ind i den sidste uge.

Det, testen skal afklare

Hvad en API-test omfatter, er beskrevet i → API-test forklaret for købere. Ved åbning for partnere er det særligt disse spørgsmål, der har betydning:

Adskillelse mellem partnere · kan én partner se eller ændre en andens data?
Rettigheder pr. partner · kan en partner kun det, aftalen giver lov til?
Nøgler og login · hvordan udstedes, begrænses og tilbagekaldes partnernes adgang?
Mængder · kan en partner hente langt mere data end forventet eller belaste systemet?
Det skjulte · findes der funktioner eller gamle versioner, som partnerne ikke skal bruge, men kan nå?

OWASP’s liste over de vigtigste sikkerhedsrisici for API’er peger blandt andet på svag autorisation på objekt- og funktionsniveau og manglende begrænsning af ressourceforbrug. Listen kan bruges som fælles sprog mellem køber og tester, men den er ikke en fuld beskrivelse af, hvad en test skal dække.

Spørgsmålene bør hænge sammen med partneraftalerne. Står der i aftalen, at en forhandler kun må se egne ordrer, er det præcis den regel, testen skal afprøve. Dokumentationen til partnerne er også et nyttigt grundlag for testeren, fordi den viser, hvad API’et lover at kunne.

Testpartnere, der ligner de rigtige

En API-test til partnere kræver mindst to testpartnere med hver deres adgang og data. Med kun én konto kan adskillelsen mellem partnere ikke afprøves. Tænk også på roller inden for en partner, hvis API’et skelner mellem fx læse- og skriveadgang. → Test med og uden login

Testdata skal ligne de rigtige nok til, at testen giver mening, men uden at rigtige kunders eller partneres oplysninger bruges. Aftal, hvem der opretter testpartnerne, og hvem der fjerner dem bagefter.

Hvis der findes test- eller udviklingsversioner af API’et på internettet, skal de med i overvejelserne. De er ofte sat op i en fart og glemt, når den rigtige version er i drift. → Glemte testmiljøer på internettet

Når partnerne spørger til sikkerheden

Partnere kan spørge, om API’et er testet, før de kobler på. Det er endnu en grund til at teste før åbningen, så svaret er klart. Hele rapporten skal sjældent deles. En kortere erklæring om, hvad der er testet, og hvornår, kan være nok. Overvej på forhånd, hvad en sådan erklæring skal indeholde, så den ikke lover mere end testen dækkede: hvilke dele af API’et der var med, hvornår testen blev gennemført, og om væsentlige fund er rettet. → Testerklæring til kunder

Spørgsmålet kan også gå den anden vej. Partnerens systemer bliver en del af kæden, og virksomheden kan have en interesse i at vide, hvordan partneren beskytter de nøgler, der giver adgang til API’et. Det er dog et spørgsmål til partnerens egen sikkerhed og ikke noget, testen af API’et kan besvare.

Det skal I lade være med

At åbne først og teste bagefter · rettelser bliver sværere, når partnere er afhængige af API’et.
At teste med én partnerkonto · adskillelsen kan ikke afprøves.
At glemme gamle versioner · en version, der stadig svarer, er en del af API’et.
At lade partneraftalen og de tekniske rettigheder leve hver sit liv · det, partneren må, skal kunne genfindes i adgangsstyringen.
At dele hele rapporten med alle partnere · overvej, hvad hver partner har brug for at vide.

Hvad kan og ikke kan konkluderes

En test før åbningen kan vise, om adskillelsen, rettighederne og adgangsstyringen holdt for de testpartnere og funktioner, der var med. Den kan give et grundlag for at åbne og for at svare partnerne, når de spørger.

Den kan ikke vise, hvordan partnernes egne systemer håndterer nøgler og data, eller hvad der sker, når API’et senere udvides eller kobles til nye systemer. Når nye partnere kommer til med nye behov, skal det vurderes, om ændringen kræver en ny test. → Integrationer mellem systemer