käytännön oppaat

Dokumentoi ja testaa API sen käyttötapauksista

Hyödyllinen API antaa toisen tiimin ymmärtää, mitä se voi pyytää ja mitä se saa. Sen sopimuksen tulee olla testattava, versioitu ja käyttöpalvelun mukainen.

Katso menetelmä

API sopimuksella

Valitse Tehtävät ennen osoitteita

Listaa käyttökohteita, kuten tuotteen löytäminen, saatavuuden lukeminen, tietueen päivittäminen tai käsittelyn seuranta. Määritä valtuutetut ihmiset ja järjestelmät kullekin toiminnolle. Julkisella READ API:lla ja hallinnollisella API:lla on erilaiset pääsyvaatimukset.

Valmistele pyyntö- ja vastausesimerkki jokaisesta olennaisesta tehtävästä käyttämällä synteettisiä arvoja ja selitettyjä kenttiä. Erottele vakaat tunnisteet, tarrat, yksiköt ja päivämäärät. Määritä puuttuvat tiedot sen sijaan, että korvaat tuntemattomilla tiedoilla uskottavia arvoja.

kuvaile selkeää sopimusta

OpenAPI tarjoaa kielestä riippumattoman kuvausmuodon HTTP-sovellusliittymille, joka kattaa toiminnot, parametrit, vastaukset ja mallit. Valitse työkalujesi tukema versio ja säilytä asiakirja projektin kanssa; Uusin versio ei automaattisesti sovi jokaiseen työkaluketjuun.

Dokumentin käyttörajoitukset, sivutus, suodattimet, tilaukset, virheet ja tyhjät vastaukset. Älä pidä CORS:ää todisteena valtuutuksesta. Tarkista toiminta ja objektitason pääsynhallinta teknisen tiimin kanssa.

Testaa rajat ja käyttöoikeudet

Kokeile olemassa olevaa objektia, puuttuvaa objektia, virheellistä parametria ja luetteloa, joka on pidempi kuin yksi sivu. Tarkista seuraavalta sivulta häviöt tai toistot valitussa päivitysmallissa. ilmoittaa rajoituksia, joita API ei voi taata.

Käytä testitilejä eri käyttöoikeuksilla. yrittää lukea ja muuttaa sallitun laajuuden ulkopuolella synteettistä dataa käyttämällä. Tallenna odotetut tilat ja hyödylliset viestit paljastamatta sisäisiä jälkiä tai konfigurointisalaisuuksia.

Suunnittele muutos ja tuki

erottaa lisätty kenttä poistetusta kentästä tai muuttuneesta merkityksestä. Tunnista kuluttajat ennen yhteensopimatonta muutosta. Selitä siirtymäkausi ja kuinka havaita integraatiot edelleen käyttämällä aikaisempaa sopimusta.

Anna suoritettava esimerkki testiympäristöstä, testimatriisista ja teknisestä kontaktista. Yhdistä havaitut virheet dokumentoituihin esimerkkeihin julkaisun jälkeen. Ihanteelliseen tapaukseen rajoittuva dokumentaatio jättää integraattorit ilman ohjeita kieltäytymis- ja keskeytysten varalta.

ensisijainen dokumentaatio: OpenAPI-aloite – eritelmät.

Sisältö päivitetty 1.10.2026

toiminnallinen validointimatriisi, joka mukautuu projektiin

Nämä ehdotetut kontrollit käyttävät kuvitteellisia tapauksia. Päätä, mitä käyttäytymistä tiimin kanssa odotetaan, kirjoita tulos muistiin ja määritä ratkaisemattomia eroja ennen julkaisemista.

testitapaukset, odotetut tulokset ja hyödyllisiä todisteita
Asiaodotettu tulostodiste säilyttää
nykyiset ja puuttuvat resurssitJokainen tulos vastaa dokumentoitua tila- ja vastausmallia.pyyntö, vastaus ja vastaava sopimusesimerkki, joka on otettu testiympäristöstä.
alueen ulkopuolinen parametriKieltäytyminen on ymmärrettävää eikä paljasta sisäistä pinojälkeä.Julkinen viesti ja tulos säilytetään hyväksymismatriisissa.
Kaksi lupatasoaKielletty resurssi ei ole käytettävissä edes tunnetulla tunnisteella.Verrattiin tuloksia käyttämällä kahta synteettistä tiliä, joilla on selvästi erilaiset käyttöoikeudet.
sivutus ja vaihdettu suodatinTokenin käsittely ja matkan uudelleenkäynnistyskäyttäytyminen määritellään.tilaus, palautetut tunnisteet ja säännöt, jotka koskevat suodattimen muuttumista.

Usein kysyttyjä kysymyksiä

Riittääkö luotu dokumentaatio API:n testaamiseen?

Se auttaa lukemaan sopimusta, mutta käyttöoikeudet, puuttuvat tiedot, virheet, luettelot ja muutokset vaativat edelleen testausta. Vertaa esimerkkejä todellisiin testiympäristön vastauksiin.

Korvaako CORS käyttöoikeudet?

Ei. Ristialkuperäsäännöt eivät korvaa palvelun toimintaa ja objektin käyttöoikeuksia. Kuvaile nämä käyttöoikeudet ja testaa palvelinpuolen täytäntöönpano testitileillä.