Definer VPN-operasjonen før du sammenligner API-er

En produktside sier at den har et API, og integreringsmøtet stopper på det andre spørsmålet. Hvilken operasjon, mot hvilket objekt, kalt av hvem, og hva regnes som suksess? Å svare på disse fire før du sammenligner produkter fjerner vanligvis halvparten av kandidatene. Det gjør også den gjenværende sammenligningen til noe en test kan avgjøre.

Erstatt «har et API» med én operasjon

Et API er en transport, ikke en evne. Et REST-endepunkt, en lokal socket og en innpakning for kommandolinjen kan alle kalles et API, og de tilbyr ikke likeverdige operasjoner.

Skriv operasjonen som en setning før du ser på dokumentasjonen.

Å starte en lokal tilkobling er en handling på klientsiden med en bruker foran seg. Å utstede en enhetsprofil er en klargjøringshandling med en inventarliste bak seg. Å deaktivere en brukers tilgang er en administrativ handling med et revisjonsspor. Disse tre ligger vanligvis i forskjellige komponenter, eid av forskjellige team, med forskjellig myndighet.

Fire felt som gjør kontrakten testbar

Fyll ut fire felt for hver operasjon: objektet, handlingen, den som kaller, og suksesskriteriet. En kontrakt med et manglende felt er et ønske.

Tabellen er hele arbeidsarket:

Suksesskriteriet er feltet folk hopper over, og det er nettopp det som avgjør om integrasjonen fungerer. En lagret innstilling er ikke en aktiv tunnel, og en deaktivert konto er ikke en avsluttet økt.

Hvis to operasjoner trenger forskjellige kallere, er de to integrasjoner. Å slå dem sammen i én tjenestekonto betyr vanligvis å gi mer myndighet enn noen av dem trenger.

Tilpass grensesnittet til laget det faktisk tilhører

OpenVPN-fellesskapets administrasjonsgrensesnitt kommuniserer med en daemon over TCP eller en Unix-socket. Kommandoene omfatter tilstandsobservasjoner og signaler til daemonen.

Det gjør det til en kontrollkanal for daemonen, ikke et driftet abonnements-API eller en tjeneste for brukerregistrering. Å lese dokumentasjonen nøye sparer deg for å bygge mot et lag som ikke eier objektet.

Dokumentasjonen sier også at protokollen ikke har egen kryptering. Den som kan nå socketen, kan styre daemonen, så behandle den som sensitiv kontroll, ikke som en metrikkestrøm. Bind den til loopback eller en Unix-socket, og sett den bak en begrenset ordning hvis en ekstern kaller trenger det. Å eksponere den mot internett for enkelhets skyld gjør en kontrollkanal til en hendelse.

Spesifiser oppførselen etter kallet

Aksept er ikke det samme som fullføring. Daemonen kan svare før tunnelen er oppe, så vent på den dokumenterte fullførings- eller feilhendelsen og knyt den til forespørselen du sendte.

Bestem hva den som kaller gjør hvis svaret går tapt. Å blindt gjenta en opprettelse eller en gjenoppkobling er ikke det samme som å sjekke om den første forespørselen allerede virket.

Fjerning av tilgang er minst tre forskjellige handlinger: blokkere fremtidig pålogging, avslutte en aktiv økt og tilbakekalle legitimasjonen. Be om dem policyen faktisk krever, og si i kontrakten hvilken som er hvilken. Ikke etiketter én vellykket kontooppdatering som fullstendig tilbakekalling uten bevis. Forskjellen betyr noe under en hendelse, når klokken går.

Kontroller kontrakten med en pilot

En liten godkjent pilot bør dekke suksess, avvisning, avbrudd og nytt forsøk, etterfulgt av applikasjonsoperasjonen som skal tillates eller avslås.

For et grensesnitt på daemonnivå utøver to kommandoer observasjon og et signal:

echo state | nc -w 2 127.0.0.1 7505
echo signal SIGTERM | nc -w 2 127.0.0.1 7505

Gi bare den myndigheten operasjonen krever. Hold hemmeligheter unna rutinelogger, og logg nok private detaljer til å si hvilket mål som ble berørt og hvordan det endte.

Skriv ned gjenopprettingsveien for tilfellet der selve kontroll-API-et er nede. Velg grensesnittet som eier objektet og livssyklusen; automatiseringspåstander på en produktside er ingen erstatning.