Sukurti ir atnaujinti pagal geografinę vietovę nukreiptų API gali atrodyti lengva, tačiau kyla daugybė iššūkių. Kiekviena šalis, kiekvienas miestas ir kiekvienas mobiliojo ryšio tinklas gali reaguoti skirtingai ir reikės skirtingų koregavimų. Kai kainodaros galutiniuose taškuose yra pagal vietą pagrįstų atitikties funkcijų ir mokėjimo parinkčių, norint juos išbandyti, reikės daugiau nei vienos fizinės vietos. Tarpiniai serveriai yra esminė kūrėjo įrankių rinkinio dalis – jie leidžia praktiškai „stovėti“ kitoje šalyje ir stebėti, ką mato vartotojai.
Kūrėjai susiduria su daugybe problemų, kai kalbama apie geografinės paskirties API testavimą, o tarpinių serverių naudojimas padeda išspręsti šią problemą. Šiame straipsnyje apibūdinsime tarpinio serverio naudojimo atvejį ir jo naudą, skirtingus tarpinio serverio tipus ir galimus iššūkius. Mes laikysimės praktiško požiūrio, kad galėtumėte perduoti jį kokybės užtikrinimo inžinieriui arba užpakalinės programos kūrėjui, o jie galės juo naudotis tiesiogiai.
Kas yra geografinės paskirties API ir kodėl jos svarbios?
Į geografinę vietovę nukreipta API yra API, kuri pritaiko savo atsakymą pagal klientų geografinę vietą. Tokios vietos pirmiausia nustatomos pagal IP adresą, kartais pagal antraštes, o tam tikrais atvejais – pagal paskyros duomenis. Srautinio perdavimo paslaugos teikia skirtingą turinį skirtingoms šalims, viešbučių užsakymo sistemos koreguoja kainas pagal geografinę vietovę, pavėžėjimo programėlės keičia valiutą pagal vietinę klientų grupę, o fintech programos apriboja matomas mokėjimo paslaugas pagal geografines mokėjimo taisykles.
Kodėl kūrėjai taip susikoncentruoja į tai? Tokios API taip pat turi būti nuoseklios, suderinamos ir nuspėjamos ir dėl geros priežasties. Kai vartotojai Lenkijoje mato kainas USD, o ne vietinius PLN, arba JK žmonės mato paslaugas, kurios jiems legaliai nepasiekiamos, gali kilti klientų nepasitenkinimas, operacijų nesėkmės arba, blogiausiu atveju, reguliavimo problemos, kurias reikia spręsti. Užtikrinti, kad geografinė logika būtų tiksliai patikrinta, neprivaloma; Viskam, kas susiję su pinigais, turiniu ar įstatymais, būtina integruota QA.
Jei komanda yra vienoje vietoje, galima nuspėti, kad visos jos bandomos užklausos yra iš tos vietos. Pasityčioti iš API yra parinktis, tačiau tai nesuteiks pakankamai informacijos apie tai, ką sugrąžins tikroji ankstesnė paslauga, ir tai yra labai svarbi informacija. Būtinas būdas užmaskuoti užklausas taip, lyg jos būtų iš kitos geografinės vietos, o tai šioje situacijoje yra įgaliotojo serverio funkcija.
Kodėl tarpiniai serveriai yra lengviausias būdas patikrinti atsakymus pagal vietą?
Tarpinis serveris veikia kaip tarpininkas, kuris perduoda jūsų užklausą tikslinei API ir grąžina atsakymą. Vienas svarbus elementas yra tai, kad API mato tik tarpinio serverio IP adresą, o ne jūsų. Darant prielaidą, kad įgaliotasis serveris yra Vokietijoje, API manys, kad užklausa gaunama iš Vokietijos; tas pats pasakytina ir apie Braziliją, API matys Braziliją. Kūrėjas gali naudoti gerą tarpinio serverio telkinį, kad išsiųstų API užklausą iš 10 skirtingų šalių ir patikrintų, ar API veikia tinkamai.
Taip pat nereikia kurti bandomosios infrastruktūros skirtinguose regionuose. Kiekvieną kartą, kai norite išbandyti, įvairiose geografinėse vietovėse nereikia nustatyti debesies egzempliorių. Jums nereikia pasikliauti kolegomis iš skirtingų šalių, kad galėtumėte dalyvauti „tik patikrinimo“ teste. Tiesiog nukreipkite užklausą per kitą IP adresą ir išanalizuokite rezultatus.
Kita tarpinių serverių populiarumo šioje užduotyje priežastis yra ta, kad jie veikia tinklo lygiu. Pačio API kodo keisti nereikia, reikia pakeisti tik API skambutį. Tai leidžia kokybės užtikrinimo inžinieriams ir užpakalinių programų kūrėjams išbandyti gamybinę elgseną nekeičiant gamybos logikos.
Įprasta darbo eiga: kaip kūrėjai iš tikrųjų naudoja tarpinius serverius testuodami
Suskaidykime tikrovišką darbo eigą, kurią pamatytumėte komandoje, kuri reguliariai tikrina geografines API.
- Apibrėžkite geografinius scenarijus
Pirmiausia komanda nusprendžia, kurias vietoves reikia išbandyti: ES ir JAV, konkrečiose šalyse, pvz., JK, Kanadoje, Vokietijoje, JAE, arba tik mobiliojo ryšio rinkas. Šis sąrašas dažnai atspindi verslo logiką API. - Pasirinkite arba pasukite tų vietų įgaliotuosius serverius
Bandytojas / kūrėjas pasirenka tarpinio serverio galinius taškus, atitinkančius tas vietas. Geras teikėjas pasiūlys didelį šalių pasirinkimą, kad neturėtumėte spragų atliekant bandymus. - Siųsti tą pačią API užklausą per skirtingus tarpinius serverius
Komanda siunčia tą patį galinio taško skambutį, tarkime, /v1/pricing?product=123, bet su klientu sukonfigūruota naudoti skirtingus tarpinio serverio IP. API turėtų pateikti skirtingas valiutas, kainas, pasiekiamumą, kalbą arba turinį, atsižvelgiant į vietą. - Užfiksuokite ir palyginkite atsakymus
Atsakymai išsaugomi ir lyginami rankiniu būdu arba naudojant automatinius testus. Jei Vokietija ir Prancūzija gauna tą patį turinį, bet turėjo skirtis, tai yra klaida. - Automatizuoti regresijai
Patvirtinus modelį, komanda jį iškepa į CI / CD arba suplanuotus testus. Kiekvieną kartą, kai įdiegiama API, bandymų rinkinys iškviečia jį iš kelių šalių per tarpinius serverius, kad įsitikintų, jog niekas nesugedo.
Tai yra pagrindinė idėja: ta pati užklausa, skirtingas išėjimo IP, palyginkite išvestį.
Kokie tarpinių serverių tipai yra geriausi Geo API testavimui?
Ne visi tarpiniai serveriai yra vienodi, o kūrėjai tai greitai išmoksta, kai pradeda naudotis tikromis paslaugomis. Kai kurios API yra griežtos, kai kurios yra švelnios, o kai kurios įtaria automatizuotą srautą. Taigi svarbu pasirinkti tinkamą tarpinio serverio tipą.
Štai paprastas palyginimas, kuris padės apsispręsti:
| Tarpinio serverio tipas | Geriausias naudojimo dėklas | Argumentai „už” | Minusai |
| Duomenų centro tarpiniai serveriai | Greitas funkcinis testavimas daugelyje šalių | Didelis greitis, geras automatizavimui, pigesnis | Kai kurios paslaugos nustato jas kaip negyvenamąsias |
| Gyvenamieji įgaliotieji serveriai | Tikrojo vartotojo sąlygų ir griežtesnių API testavimas | Didelis pasitikėjimas, atrodo kaip įprastas vartotojų srautas | Lėtesnis, dažnai brangesnis |
| Mobilieji tarpiniai serveriai | Tik mobiliesiems skirtų funkcijų ir programos galinių taškų testavimas | Laikoma mobiliųjų įrenginių naudotojams, puikiai tinka programų testavimui | Brangiausias, ribotas prieinamumas |
| Besisukantys tarpiniai serveriai | Didelio masto kelių geografinių sistemų automatizuotas testavimas | IP šviežumas, mažiau blokuoja daug skambučių | Sunkiau derinti vieno fiksuoto IP elgseną |
Daugeliui galinių komandų duomenų centro tarpinių serverių pakanka logikai patikrinti: ar API grąžina EUR Vokietijos IP, o GBP – JK IP? Kokybės užtikrinimo komandoms, tikrinančioms į gamybą panašius srautus, gyvenamieji arba mobilieji tarpiniai serveriai yra geresni, nes daugelis šiuolaikinių API suasmenina turinį arba taiko saugos taisykles pagal suvokiamą IP „tikroviškumą“.
Jei jums reikia lankstaus geografinių IP šaltinio kūrėjams ir kokybės užtikrinimui, naudoti tokį teikėją kaip proxys.io yra patogu, nes galite pasirinkti vietas pagal poreikį ir prijungti jas prie scenarijų be pernelyg sudėtingos sąrankos.
Pagrindinių dalykų kūrėjų testas su tarpiniais serveriais
Kūrėjai nenaudoja tarpinių serverių pramogai; jie naudoja juos atsakydami į labai konkrečius klausimus apie tai, kaip veikia geografinė API. Čia pateikiamos dažniausiai jų patvirtinamos sritys:
- Valiuta ir lokalizacija (USD vs EUR vs GBP, datos formatai, kalbų antraštės)
- Pasiekiamumas regione (ar šis produktas / paslauga iš tikrųjų rodoma šioje rinkoje?)
- Slėpimas pagal atitiktį (ar ribojamas turinys paslėptas konkrečiose šalyse?)
- Kainodaros pakopos (ar dideles pajamas gaunantys regionai skiriasi kainų laiptais?)
- Mokėjimo šliuzai (ar tam tikras mokėjimo būdas matomas toje šalyje?)
- Funkcijų vėliavėlės, susietos su geografija (pvz., funkcijos, išleistos tik 3 rinkose)
Vykdydamas tą patį skambutį per 5–10 skirtingų šalių tarpinių serverių, kūrėjas iš karto mato, ar verslo taisyklės tinkamai užkoduotos API.
Vienas praktinis sąrašas: geriausia tarpinių serverių naudojimo API testavimo praktika
- Naudokite HTTPS visam tarpinio serverio srautui, kad išvengtumėte klastojimo ir atspindėtumėte naudojimą realiame pasaulyje.
- Savo bandymo atpirkime pažymėkite „šalis → tarpinio serverio galutinis taškas“, kad bandymai būtų atkuriami.
- Užregistruokite IP ir šalį, naudojamą kiekvienam bandomajam paleidimui – tai labai palengvina derinimą.
- Nepasikliaukite tik vienu IP kiekvienoje šalyje; kai kurios API talpykloje saugos atsakymus pagal IP.
- Pridėkite tvirtinimus pagal šalį automatiniuose testuose („jei šalis = DE, tikimasi valiutos = EUR”).
- Periodiškai pasukite arba atnaujinkite tarpinius serverius, kad išvengtumėte pasenusių ar užblokuotų IP.
- Dokumentų testavimo aprėptis, kad produktų savininkai žinotų, kuriose šalyse iš tikrųjų yra bandoma.
Tai tokia higiena, kuri paverčia tarpinius serverius iš ad hoc gudrybės į stabilią jūsų kokybės užtikrinimo sistemos dalį.
Kaip integruoti geografinio tarpinio serverio testavimą į automatizuotus vamzdynus
Daugelis komandų pradeda testavimą rankiniu būdu naudodami tarpinį serverį „Postman“, „Insomnia“ ar „Curl“. Tai tinka atradimui, bet nepakanka ilgalaikiam patikimumui. Tikras laimėjimas yra tada, kai į CI / CD įtraukiate kelių geografinių tyrimų testus, todėl kiekvienas diegimas automatiškai tikrina elgseną pagal vietą.
Modelis yra paprastas:
- Jūsų bandomajame rinkinyje yra tikslinių šalių sąrašas.
- Kiekvienai šaliai bandytojas nustato tarpinio serverio konfigūraciją.
- Bėgikas iškviečia API ir užfiksuoja atsakymą.
- Testas palygina atsaką su numatoma forma / turiniu toje šalyje.
- Jei net vienai šaliai nepavyksta (pavyzdžiui, Kanada negauna CAD), sugenda dujotiekis.
Kai tarpiniai serveriai suteikia supaprastintą tinklo lygio sąsają, ji yra suderinama su beveik bet kokia kalba ar testavimo sistema, nesvarbu, ar tai JavaScript (Axios, mazgų gavimas), Python (užklausos), Java (HttpClient), Go (http.Client su transportu) ar net cURL pagrįstas Bash scenarijus. Būtina nustatyti kiekvienos užklausos tarpinį serverį.
Tai labai naudinga komandoms, diegiančioms progresyvias geografinės išleidimo funkcijas. Tarkime, rinkodaros komanda nori išleisti funkciją JK ir Vokietijoje, bet ne JAV. Jūsų nuolatinė integravimo sistema galėtų įgyvendinti šią taisyklę. Jei JAV staiga gaus šią funkciją, kūrimas nepavyks. Tai yra kontrolė.
Dažni spąstai ir kaip jų išvengti
Nors tarpiniu serveriu pagrįstas testavimas iš esmės yra paprastas, kūrėjai susiduria su kai kuriomis pasikartojančiomis problemomis:
1. API vietai nustatyti naudoja daugiau nei IP
Kai kurios API taip pat žiūri į Accept-Language, SIM / Carrier duomenis (mobiliesiems) arba paskyros nustatymus. Jei pakeisite tik IP, galite suaktyvinti ne visas geografines šakas. Sprendimas: jei įmanoma, atspindėkite antraštes ir vartotojo profilio sąlygas.
2. Talpykla paslepia skirtumus
Jei aukštesnės srovės paslauga talpykloje saugoma tik pagal URL (ne pagal IP), galite gauti tą patį atsakymą net ir keičiant šalį. Sprendimas: pridėkite talpyklos blokavimo užklausos parametrus arba įsitikinkite, kad API sukonfigūruota taip, kad skirtųsi pagal IP.
3. Nemokamų arba žemos kokybės tarpinių serverių naudojimas
Nepatikimi tarpiniai serveriai sukelia klaidingus neigiamus rezultatus – pasibaigia skirtasis laikas, blokuojami IP arba netinkamos šalys. Verslo logikos testavimui stabilūs ir teisingos geografinės vietos IP yra svarbesni nei dolerio sutaupymas.
4. Laiko juostų pamiršimas
Kai kurios paslaugos susieja geografinę logiką su vietos laiku. Jei tikrinate tik IP, bet ne laiko langą, galite manyti, kad funkcijos trūksta. Laiku pagrįstas taisykles dokumentuokite atskirai.
5. Neregistruojamas tarpinio serverio naudojimas
Kai kas nors praneša „Vokietija negavo tinkamų kainų“, turite žinoti, kurį IP naudojote. Visada užregistruokite tarpinio serverio galinį tašką ir šalį, kad būtų galima atsekti.
Šių klaidų išvengimas daro geografinį testavimą naudojant tarpinius serverius itin patikimus.
Kodėl tarpiniai serveriai įveikia rankinį nuotolinį testavimą
Galite paprašyti kolegos iš Ispanijos spustelėti jūsų nuorodą. Galite nustatyti debesies egzempliorius 12 regionų. Galėjai net keliauti. Tačiau šios parinktys yra lėtos, brangios ir nepakartojamos. Kita vertus, įgaliotieji serveriai:
- Dirbkite iš karto iš dabartinės vietos
- Pritaikykite tiek šalių, kiek palaiko jūsų teikėjas
- Galima paleisti CI/CD, ne tik rankiniu būdu
- Nepriklausomi nuo jūsų asmeninio įrenginio ar IP
- Lengva pasukti, jei vienas IP yra užblokuotas
Inžineriniu požiūriu jie yra paprasčiausias būdas imituoti skirtingas naudotojų geografines vietas.
Išvada: tarpiniai serveriai geografinį testavimą paverčia pakartojamu procesu
Visur yra geografinės paskirties API – komercija, turinys, fintech, mobilumas, žaidimai, SaaS. Bet kuris produktas, kurį naudojate keliose šalyse, galiausiai turės išspręsti klausimą: „Kaip tai atrodo X naudotojams? Įgaliotieji serveriai suteikia švariausią būdą kūrėjams programiškai atsakyti į šį klausimą.
Kūrėjai gali patikrinti, ar kainos, valiutos, kalbos, prieinamumas ir atitikties taisyklės veikia taip, kaip tikėtasi, pakeisdami tą patį API iškvietimą, kad būtų naudojami skirtingų šalių IP. Naudodami gerą tarpinio serverio teikėją galite tai paversti iš vienkartinio derinimo technikos į standartinį patikrinimą savo testavimo procese.
Išvada paprasta: jei API logika pagrįsta vartotojo vieta, turi būti ir testavimas. Tarpiniai serveriai yra būdas tai pasiekti nuo savo stalo.
