
Sokan talán nem tudják, de a Sitata korai alapjai a betegségek korai felismerésére épültek. Valójában az alapítónknak van egy 2016-os TedX előadása a miért kell figyelmeztetni az utazókat, hogy megelőzzük a betegségek terjedését. Nem meglepő tehát, hogy a COVID-19-et akkor vettük fel, amikor 2019 decemberének elején a tüdőgyulladás szokatlan csoportosulásaként jelentették. 2020. január 2-án az egészségügyi csoportunk úgy döntött, hogy ki kell adnunk első figyelmeztetésünk utasainknak és üzleti partnereinknek. Ez még az Egészségügyi Világszervezet előtt volt!
Az elkerülhetetlen bukás során megvilágosodtunk. A betegség olyan gyorsan terjedt, hogy világossá vált számunkra, hogy a globális válaszlépés a legjobb esetben is kaotikus lesz. Minden ország a saját szabályozásait és szabályait hozná meg a terjedés megfékezésére. Ez elkerülhetetlenül pusztítást okozna a globális utazásban, és hatalmas zűrzavart okozna azok számára, akik még mindig utazni szeretnének. Igazunk volt, és nekiláttunk, hogy tegyünk valamit ez ellen. A Sitata volt az egyik első olyan vállalat a világon, amely a COVID-19 következtében az utazási korlátozásokban és a beutazási követelményekben bekövetkező változásokra dedikált API-t és megfigyelő szolgáltatást hozott létre. Az események észlelésére szolgáló fejlett szoftverrendszerrel és egy dedikált elemzői csapattal már rendelkeztünk az összes megfelelő eszközzel és folyamattal.
Az új szolgáltatás elindítása óta számos szervezet használta ki az adatokat saját ügyfelei javára, köztük az Eddy Travels, a Flight Centre és az Etihad Airways; és hamarosan még több bejelentés érkezik! Annak érdekében, hogy még több utazásra összpontosító szervezet részesülhessen ebből az ajánlatból, az alábbiakban részletesen leírtunk néhány példát, amelyek segítenek elmagyarázni, hogyan lehet az API-t különböző felhasználási esetekben használni. Remélem, ezek a magyarázatok segítenek a saját kezdeményezéseik elindításában.
Kétségtelen, hogy az utazók első kérdései a következők: "mehetek-e oda?" és "leszek-e karanténban", ezért ez egy jó kiindulópont. A beutazási követelmények adatkészletet azért hoztuk létre, hogy választ adjunk az országba vagy régióba való beutazással kapcsolatos kemény "igen/nem" típusú kérdésekre.
Az írás időpontjában ez az adatkészlet a következő 10 különböző kategóriát tartalmazta:
Minden kategória a következő értékek egyikével rendelkezhet:
Bár az értékek túlnyomó többsége "igen" és "nem", a helyzet a helyszínen nem mindig ilyen egyértelmű. Néha vannak igazán furcsa és őrült szabályok, amelyeket a különböző kormányok hoztak, és amelyek szükségessé teszik az értéktípusok "kivételekkel" történő alkalmazását.
A belépési követelmény lényegében egy olyan rekord, amely egy szereplő által egy vagy több más országgal vagy régióval szemben előírt szabályrendszert dokumentál. A szereplő lehet ország, állam vagy akár önkormányzat is az adatarchitektúránkban. A Sitata jelenleg nagyjából országos szintű adatokat tartalmaz. Ugyanakkor van néhány állami/provinciális rekordunk bizonyos régiókra, például az Egyesült Államokra és más régiókra vonatkozóan.
Minden olyan rekord, amely a origin_country_division_id
vagy származási_ország_régió_id
állami vagy önkormányzati szintű. Ha részletesebb adatokat szeretne kapni, kérjük, hogy kapcsolatfelvétel és megbeszélhetjük az Ön felhasználási esetét.
Kérjük, szánjon egy kis időt arra, hogy megismerkedjen a belépési követelmények adatszerkezetével az alábbiak szerint. az API dokumentációnkat itt nézheti meg.
Az adatstruktúrával kapcsolatban egy kissé zavaró rész az, hogy a "eredet." Ez azért zavaró, mert a fejlesztők gyakran úgy gondolnak az eredetre, mint a kiindulási vagy az indulási helyre. Az eredet alatt azonban valójában a másokra kényszerített szabály eredetét értjük, azaz azt az országot vagy régiót, amely a korlátozást létrehozta.
Egy másik fontos szempont, hogy hogyan működik az érintett országok listája. Ha az affected_countries üres, akkor azt globális szabályként kell értelmezni, azaz minden ország érintett.
Amint azt a dokumentációból már láthattad, az API-ból többféleképpen is lekérdezhetsz adatokat. Az alábbiakban néhány gyakori felhasználási esetet tekintünk át.
Az ilyen típusú kérésnek többféle módja is van. A legegyszerűbb változat a célállomás
és indulás
paraméterek. Ezek a paraméterek elfogadják ISO 3166-1 alpha-2 kódok bemenetként.
GET https://www.sitata.com/api/v2/entry_requirements?departure=DE&destination=IN
A válasz tartalmazza az indulási országból induló és a célországba utazó utazó számára szükséges valamennyi (ország- és állami szintű) követelményt.
A Sitata bizonyos régiókra vonatkozóan rendelkezik állami szintű adatokkal. Egy adott bejegyzést akkor ismerhet fel, ha az államra vonatkozik, ha a származási_ország_felosztás
mezőnek van értéke. Szűrhet úgy is, hogy csak az állapotszintű adatokat kérje le a célország_ország_felosztás
paraméter. Ez elvárja a ISO_3166-2 érték. Például: US-TX a Texas, Egyesült Államok.
GET https://www.sitata.com/api/v2/entry_requirements?departure=DE&destination_country_division=IN-AP
Megjegyzendő, hogy egyszerűbb lehet az országonkénti lekérdezés, majd az állami adatok szűrése, hogy megnézzük, léteznek-e ilyen adatok, és ha léteznek, használjuk őket.
Az országokhoz hasonlóan a Sitata API két repülőtér között is képes eredményeket szolgáltatni. A paraméterek departure_airport
és célállomás_repülőtér
vagy ICAO vagy IATA kódok az eredmények szűréséhez. A válasz tartalmazza az összes olyan korlátozást (ország- és államszintű), amely a megfelelő indulási országból induló és a célországba utazó utazó személyre vonatkozik.
GET https://www.sitata.com/api/v2/entry_requirements?departure_airport=MUC&destination_airport=BOM
A válasz tartalmazza az indulási országból induló és a célországba utazó utasra vonatkozó összes szükséges korlátozást (országos és állami szinten).
A Sitata úgy döntött, hogy nem fogadja be a városnév szerinti lekérdezéseket, mivel ez konfliktusokhoz és zűrzavarhoz vezethet. Ehelyett úgy döntöttünk, hogy az API-nkat a szélességi és hosszúsági koordináták alapján is lekérdezhetjük, ami nem eredményez többértelműséget az eredményhalmazban. A paraméterek a következők departure_lat
, departure_lng
, destination_lat
, és destination_lng
.
GET https://www.sitata.com/api/v2/entry_requirements?departure_lat=48.13743&departure_lng=11.57549&destination_lat=19.0760&destination_lng=72.8777
Ha a városokat helyekre bontja, és a koordináták alapján kérdezi le, az API-nk az összes olyan korlátozással (ország- és államszintű) válaszol, amely az indulási országból induló és a célországba utazó utazó számára szükséges.
A belépési követelmények egyes típusaihoz további kapcsolódó adatok is tartozhatnak egy metaadat-típusú mezőben, az úgynevezett extrák
. Ez a mező egy kulcs/érték leképezés különböző extra információ biteket tartalmaz egy adott követelményhez.
Ez az adatbevitel a belépési követelmény alá tartozik 5. típus. Ebben a bejegyzésben a extrák
leképezés tartalmazni fog egy mezőt karantén_napok
amely egy egész számot tartalmaz, amely a karantén napok számát jelzi.
Ez az adatbevitel a belépési követelmény alá tartozik 8-as típus. Ebben a bejegyzésben a extrák
leképezés tartalmazni fog egy mezőt entry_hours
amely egy egész számot tartalmaz, amely azt az óraszámot jelzi, ameddig a negatív covid-teszt a belépés előtt engedélyezett.
Úgy gondoljuk, hogy egy nagyon robusztus, valószínűleg minden igényt kielégítő csomaggal rendelkezünk, amely segít az utazóknak megérteni, hogy valószínűleg mivel fognak találkozni útközben. Ha van olyan konkrét felhasználási esete, amellyel nem foglalkozunk, kérjük, értesítsen minket!
Ez a bejegyzés egy kétrészes sorozat része, amely elmagyarázza, hogyan léphet kapcsolatba a Sitata API-val a beutazási követelményekre és utazási korlátozásokra vonatkozó információkért. Eddig a beutazási követelményekről beszéltünk, amelyek egy országba vagy régióba való belépéshez szükséges kemény igen/nem típusú követelményeket vázolnak fel, de arról még nem beszéltünk, hogy mi történik az országon belül. Egy dolog tudni egy országba való beutazásról, más dolog megérteni, hogy lehet-e az országban mozogni, vagy meglátogatni a strandokat, vagy van-e kötelező kijárási tilalom.
Maradjon velünk a második bejegyzéshez, amely mélyen belemerül a Travel Restriction adathalmazunkba. Tipp - ez majdnem azonos, így bármikor megnézheti a mi API dokumentáció addig is.