Sano de prokurilo: kiun retejon kaj operacion vi testis?
Apartigu ĝeneralan atingeblon de la prokurilo disde celospecifaj paneoj, kiam vi prizorgas reuzeblan provizon da prokuriloj.
Prokurilo elprenas vian IP-kontrolpaĝon kaj paneas ĉe la API, kiun via aplikaĵo bezonas. Nomante ĝin “sana” aŭ “morta” oni perdas la plej utilan fakton: la du petoj estis malsamaj.
Komencu per transportnivela rikordo por la finpunkto. Ĉu vi povas atingi ĝian aŭskultanton kaj plenumi la bezonatan prokurilan intertraktadon? Konservu celospecifajn observojn apud tiu rikordo anstataŭ anstataŭigi ĝin.
| Observo | Esplorota amplekso |
|---|---|
| Prokurila aŭskultanto rifuzas konektojn | La finpunkto kaj la itinero al ĝi |
| Prokurilo rifuzas unu celan pordon | La permesita operacio por tiu celo |
| Unu retejo redonas kontan eraron | La cela aplikaĵo kaj la legitimiloj |
| Grandaj respondoj haltas, malgrandaj finiĝas | La transiga laborŝarĝo kaj la tempolima politiko |
HTTP-respondo povas pruvi, ke peta vojo redonis ion, dum ĝi ankoraŭ estas neuzebla por la aplikaĵo. Konservu transportan sukceson, HTTP-statuson kaj atendatan enhavon kiel apartajn rezultojn.
Se unu celo paneas ripete, paŭzu aŭ esploru tiun paron finpunkto-kaj-celo. Malŝalti la prokurilon por ĉiu nerilata tasko povas forĵeti utilan kapaciton. Male, tutmonda konekta paneo ne devus resti kaŝita malantaŭ la izolita rikordo de unu retejo.
Praktika sanŝlosilo povas inkluzivi la prokurilan identigilon, la celan servon kaj la operacian tipon. Evitu uzi la tutan legitimilan URL-on aŭ ĉiun unikan rimedan vojon kiel konstante kreskantan ŝlosilon. Grupigu nur tie, kie la grupigo donas senchavan prognozon pri la sekva peto.
La celo estas pli bona enkursiga pruvo, ne pli granda kolekto de verdaj insignoj. Sana rezulto devus diri, kio estis provita, kiam, kaj kion ĝi fakte konstatis.