Määritä VPN-toiminto ennen kuin vertailet API-rajapintoja

Tuotesivu väittää, että siinä on API, ja integraatiopalaveri jumittuu toiseen kysymykseen. Mikä toiminto, mihin objektiin, kenen kutsumana ja mikä lasketaan onnistumiseksi? Näihin neljään vastaaminen ennen tuotteiden vertailua karsii yleensä puolet ehdokkaista. Se tekee myös jäljelle jäävästä vertailusta jotain, minkä testi voi ratkaista.

Korvaa väite API:sta yhdellä toiminnolla

API on siirto, ei kyky. REST-päätepiste, paikallinen socket ja komentorivikääre voivat kaikki olla API, eivätkä ne tarjoa vastaavia toimintoja.

Kirjoita toiminto lauseena ennen kuin avaat dokumentaation.

Paikallisen yhteyden aloittaminen on asiakaspuolen toimenpide, jonka edessä on käyttäjä. Laiteprofiilin myöntäminen on valmistelutoimenpide, jonka takana on laiteluettelo. Käyttäjän pääsyn poistaminen on hallinnollinen toimenpide, jolla on auditointijälki. Nämä kolme elävät yleensä eri komponenteissa, eri tiimien omistuksessa ja eri valtuuksin.

Neljä kenttää, jotka tekevät sopimuksesta testattavan

Täytä jokaisesta toiminnosta neljä kenttää: objekti, toiminto, kutsuja ja onnistumisen ehto. Sopimus, josta kenttä puuttuu, on toive.

Taulukko on koko työarkki:

Onnistumisen ehto on kenttä, jonka ihmiset ohittavat, ja juuri se ratkaisee, toimiiko integraatio. Tallennettu asetus ei ole aktiivinen tunneli, eikä poistettu käyttäjä ole päättynyt istunto.

Jos kaksi toimintoa tarvitsee eri kutsujat, kyse on kahdesta integraatiosta. Niiden niputtaminen yhteen palvelutiliin tarkoittaa yleensä enemmän valtuuksia kuin kumpikaan tarvitsee.

Sovita rajapinta sen todelliseen kerrokseen

OpenVPNin yhteisön hallintarajapinta puhuu daemonin kanssa TCP:n tai Unix-socketin kautta. Sen komentoihin kuuluvat tilan havainnointi ja daemonille lähetettävät signaalit.

Tämä tekee siitä daemonin ohjauskanavan, ei isännöityä tilaus-API:a eikä käyttäjien rekisteröintipalvelua. Sen dokumentaation huolellinen lukeminen säästää rakentamasta kerroksen päälle, joka ei omista objektia.

Sama dokumentaatio kertoo, ettei protokolla kanna omaa salaustaan. Kuka tahansa socketiin pääsevä voi ohjata daemonia, joten kohtele sitä arkaluonteisena ohjauksena, ei mittarivirtana. Sido se loopbackiin tai Unix-socketiin ja aseta rajoitetun järjestelyn taakse, jos etäkutsuja tarvitsee sitä. Sen paljastaminen internetiin mukavuuden vuoksi muuttaa ohjauskanavan tapaukseksi.

Määritä käyttäytyminen kutsun jälkeen

Hyväksyntä ei ole sama kuin valmistuminen. Daemon voi palata ennen kuin tunneli on pystyssä, joten odota dokumentoitua valmistumis- tai epäonnistumistapahtumaa ja sido se lähettämääsi pyyntöön.

Päätä, mitä kutsuja tekee, jos vastaus katoaa. Luomisen tai uudelleenyhdistämisen sokea toistaminen ei ole sama kuin sen tarkistaminen, onko ensimmäinen pyyntö jo vaikuttanut.

Pääsyn poistaminen on vähintään kolme eri toimenpidettä: estä tuleva kirjautuminen, lopeta käynnissä oleva istunto ja peruuta valtuustieto. Pyydä ne, joita käytäntö todella vaatii, ja kerro sopimuksessa, mikä on mikä. Älä leimaa yhtä onnistunutta tilitapahtumaa täydelliseksi peruutukseksi ilman todisteita. Ero on merkityksellinen tapauksen aikana, kun kello käy.

Tarkista sopimus pilottihankkeella

Pienen hyväksytyn pilottihankkeen tulisi kattaa onnistuminen, hylkäys, keskeytys ja uudelleenyritys, ja sen jälkeen sovellustoiminto, joka pitäisi sallia tai kieltää.

Daemonitason rajapinnalle kaksi komentoa harjoittaa havainnointia ja signaalia:

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

Myönnä vain se valtuus, jota toiminto vaatii. Pidä salaisuudet poissa rutiinilokeista ja kirjaa tarpeeksi yksityiskohtia, jotta voit kertoa, mihin kohteeseen se vaikutti ja miten se päättyi.

Kirjoita palautumispolku tilanteeseen, jossa ohjaus-API itse on alhaalla. Valitse rajapinta, joka omistaa objektin ja sen elinkaaren; tuotesivun automaatioväitteet eivät ole korvike.