Construiți și configurați un instrument

Începeți cu documentația oficială API pentru serviciul de afaceri și o sarcină pe care contul dvs. este permis să o îndeplinească. Un instrument restrâns și bine descris este mai ușor de testat decât un instrument generic care acceptă o adresă URL și o metodă arbitrare.

Definiți cererea#

Dați instrumentului un nume stabil și o descriere care explică scopul său, limitele importante și dacă modifică datele. Selectați metoda HTTP documentată și punctul final. Utilizați substituenți numai pentru elementele de cale variabilă pe care operația le permite de fapt.

Pentru o căutare de înregistrare fictivă, calea poate conține un identificator de înregistrare. Numele de gazdă și regiunea contului ar trebui să rămână parte a conexiunii configurate, mai degrabă decât intrarea modelului deschis.

Definiți și mapați intrările#

Utilizați schema de intrare pentru a descrie fiecare câmp, tipul acestuia, starea necesară și valorile valide. O mică schemă pentru o căutare fictivă este:

{
  "type": "object",
  "properties": {
    "record_id": {
      "type": "string",
      "description": "The verified identifier of the record to read"
    }
  },
  "required": ["record_id"],
  "additionalProperties": false
}

Mapați argumentele către câmpurile documentate de cale, interogare sau corp. Verificați dacă câmpurile obligatorii lipsă și argumentele suplimentare neașteptate eșuează clar. Păstrați autentificarea în conexiunea la server acceptată, nu într-un prompt, o schemă de exemplu sau un antet de instrument codificat.

Modelați rezultatul#

Maparea sau transformarea răspunsurilor poate returna câmpurile de care fluxul de lucru are nevoie în loc de răspunsul întregului serviciu. Verificați ieșirea transformată față de rezultatul testului original. Nu eliminați identificatorul de înregistrare, informațiile de paginare sau detaliile de eroare necesare pentru a înțelege dacă rezultatul este complet.

Examinați setările de operare#

Configurația instrumentului acceptă setările de timeout, cache și reîncercare. Utilizați stocarea în cache numai atunci când datele învechite sunt acceptabile; o citire în cache este nepotrivită ca dovadă finală că o scriere tocmai a fost finalizată. Reîncercarea unei scrieri non-idempotente poate crea duplicate, așa că alegeți comportamentul de reîncercare din garanțiile documentate ale API.

Testează calea reală#

Verificați intrarea corectă, intrarea nevalidă, rezultatele goale, eșecul permisiunii și un apel limitat cu succes. Testele de diagnosticare pot conține informații sensibile de solicitare; inspectați-le numai prin ruta aprobată de administrator și redactați înainte de partajare. Vezi testarea înainte ca un client să folosească instrumentul.