Definiera VPN-åtgärden innan du jämför API:er

En produktsida säger att den har ett API, och integrationsmötet fastnar på den andra frågan. Vilken åtgärd, mot vilket objekt, anropad av vem, och vad räknas som framgång? Att svara på dessa fyra innan du jämför produkter tar vanligtvis bort hälften av kandidaterna. Det gör också den återstående jämförelsen till något ett test kan avgöra.

Byt ut «har ett API» mot en åtgärd

Ett API är en transport, inte en förmåga. En REST-slutpunkt, en lokal socket och ett kommandoradsomslag kan alla kallas API, och de erbjuder inte likvärdiga åtgärder.

Skriv åtgärden som en mening innan du tittar på dokumentationen.

Att starta en lokal anslutning är en åtgärd på klientsidan med en användare framför sig. Att utfärda en enhetsprofil är en försörjningsåtgärd med ett inventarium bakom sig. Att inaktivera en användares åtkomst är en administrativ åtgärd med ett granskningsspår. Dessa tre bor vanligtvis i olika komponenter, ägs av olika team och har olika befogenhet.

Fyra fält som gör kontraktet testbart

Fyll i fyra fält för varje åtgärd: objektet, åtgärden, anroparen och framgångsvillkoret. Ett kontrakt med ett saknat fält är en önskan.

Tabellen är hela arbetsbladet:

Framgångsvillkoret är fältet folk hoppar över, och det är just det som avgör om integrationen fungerar. En sparad inställning är inte en aktiv tunnel, och ett inaktiverat konto är inte en avslutad session.

Om två åtgärder behöver olika anropare är de två integrationer. Att slå ihop dem i ett tjänstekonto innebär vanligtvis att ge mer befogenhet än någon av dem behöver.

Anpassa gränssnittet till det lager det faktiskt tillhör

Gemenskapens administrationsgränssnitt i OpenVPN talar med en daemon över TCP eller en Unix-socket. Dess kommandon omfattar tillståndsobservationer och signaler till daemonen.

Det gör det till en kontrollkanal för daemonen, inte ett hostat prenumerations-API eller en tjänst för användarregistrering. Att läsa dess dokumentation noggrant sparar dig från att bygga mot ett lager som inte äger objektet.

Dokumentationen säger också att protokollet inte har egen kryptering. Den som kan nå socketen kan styra daemonen, så behandla den som känslig kontroll, inte som ett mätvärdesflöde. Bind den till loopback eller en Unix-socket, och sätt den bakom ett begränsat arrangemang om en fjärranropare behöver det. Att exponera den mot internet för enkelhetens skull gör en kontrollkanal till en incident.

Ange beteendet efter anropet

Accept är inte samma sak som slutförande. Daemonen kan svara innan tunneln är uppe, så vänta på den dokumenterade slutförande- eller felhändelsen och knyt den till begäran du skickade.

Bestäm vad anroparen gör om svaret går förlorat. Att blint upprepa en skapelse eller en återanslutning är inte samma sak som att kontrollera om den första begäran redan haft effekt.

Att ta bort åtkomst är minst tre olika åtgärder: blockera framtida inloggning, avsluta en aktiv session och återkalla behörighetsuppgiften. Be om dem som policyn faktiskt kräver, och säg i kontraktet vilken som är vilken. Etikettera inte en lyckad kontouppdatering som fullständig återkallning utan bevis. Skillnaden spelar roll under en incident, när klockan går.

Kontrollera kontraktet med en pilot

En liten godkänd pilot bör täcka framgång, avvisande, avbrott och nytt försök, följt av applikationsåtgärden som ska tillåtas eller nekas.

För ett gränssnitt på daemonnivå utövar två kommandon observation och en signal:

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

Bevilja bara den befogenhet åtgärden kräver. Håll hemligheter borta från rutinloggar, och logga tillräckligt med privata detaljer för att säga vilket mål som påverkades och hur det slutade.

Skriv ner återställningsvägen för fallet där själva kontroll-API:et ligger nere. Välj det gränssnitt som äger objektet och dess livscykel; automationspåståenden på en produktsida är ingen ersättning.