كيفية استخدام واجهات برمجة تطبيقات سيتاتا لتحديد قيود السفر للمسافرين

قد لا يعرف الكثير منكم هذا، لكن الأسس الأولى لـ Sitata بُنيت للكشف المبكر عن الأمراض. في الواقع، لدى مؤسسنا حديث في TedX يعود لعام 2016 يتناول لماذا نحتاج إلى تحذير المسافرين للمساعدة في منع انتشار الأمراض. لذا، لا ينبغي أن يكون مفاجئًا أننا التقطنا إشارات كوفيد-19 عندما تم الإبلاغ عنه كمجموعة غير عادية من حالات الالتهاب الرئوي في أوائل ديسمبر 2019. وبحلول 2 يناير 2020، قرر فريقنا الصحي أنه يجب علينا إصدار تحذيرنا الأول لمسافرينا وشركائنا التجاريين. وكان هذا قبل أيام من منظمة الصحة العالمية نفسها!

خلال التبعات الحتمية للأزمة، أدركنا فجأة. كان المرض ينتشر بسرعة لدرجة أننا تأكدنا أن الاستجابة العالمية ستكون فوضوية في أحسن الأحوال. سيكون لكل دولة مجموعة خاصة بها من اللوائح والقواعد للسيطرة على الانتشار. وهذا سيلحق حتمًا فوضى كبيرة بالسفر العالمي وسيكون مصدرًا هائلًا للارتباك لأولئك الذين لا يزالون يرغبون في السفر. كنا على حق وشرعنا في فعل شيء حيال ذلك. كانت Sitata من أوائل الشركات في العالم التي أنشأت واجهة برمجة تطبيقات (API) وخدمة مراقبة مخصصة لتتبع تغيرات قيود السفر ومتطلبات الدخول الناتجة عن كوفيد-19. ومع نظام برمجي متقدم للكشف عن الأحداث وفريق مخصص من المحللين، كانت لدينا بالفعل جميع الأدوات والعمليات المناسبة للقيام بذلك.

منذ إطلاق هذه الخدمة الجديدة، استفادت مجموعة متنوعة من المنظمات من البيانات لصالح عملائها الخاصين، بما في ذلك Eddy Travels وFlight Centre وEtihad Airways؛ وهناك المزيد سيُعلن عنه قريبًا! لمساعدة المزيد من المنظمات المرتكزة على السفر للاستفادة من هذا العرض، كتبنا بالتفصيل أدناه عددًا من الأمثلة لشرح كيفية استخدام واجهة برمجة التطبيقات (API) لحالات استخدام متنوعة. آمل أن تساعدك هذه الشروحات في إطلاق مبادراتك الخاصة.

متطلبات الدخول

بلا شك، أول الأسئلة التي يطرحها المسافر هي “هل يمكنني الذهاب إلى هناك؟” و”هل سأخضع للحجر الصحي؟”، لذا فهذه نقطة بداية جيدة. أنشأنا مجموعة بيانات “متطلبات الدخول” للإجابة على أسئلة “نعم/لا” الصارمة المتعلقة بدخول دولة أو منطقة.

في وقت كتابة هذا المقال، تضمنت مجموعة البيانات هذه 10 فئات متميزة:

هل يمكن لمواطن الدولة الدخول؟
هل يمكن لأجنبي الدخول إلى الدولة؟
هل يُسمح بالعبور عبر الدولة؟
هل يلزم إجراء فحص عند الوصول (تفشي مرض)؟
هل يُسمح بشهادة فحص (تفشي مرض)؟
هل يلزم الحجر الصحي عند الوصول (تفشي مرض)؟
هل يلزم التطعيم؟
هل يلزم التأمين؟
هل يلزم شهادة فحص؟
هل يلزم نموذج دخول؟ (صحي أو غيره)

يمكن أن يكون لكل فئة إحدى القيم التالية:

نعم
نعم، مع استثناءات
لا
لا، مع استثناءات

بينما الغالبية العظمى من القيم هي “نعم” و”لا”، فإن الواقع على الأرض ليس دائمًا بهذه البساطة. في بعض الأحيان، تضع الحكومات المختلفة قواعد غريبة جدًا ومجنونة مما يستدعي وجود قيم من نوع “مع استثناءات”.

“متطلب الدخول” هو في الأساس سجل يوثق مجموعة من القواعد التي يفرضها فاعل (جهة) ضد دولة أو دول أخرى أو مناطق. يمكن أن يكون هذا الفاعل دولة، أو ولاية، أو حتى بلدية في بنيتنا للبيانات. بشكل عام، تغطي Sitata حاليًا بيانات على مستوى الدولة. ومع ذلك، لدينا بعض السجلات على مستوى الولاية/المقاطعة لمناطق مختارة مثل الولايات المتحدة وغيرها.

أي سجل يحتوي على إدخال في الحقل **origin_country_division_id** أو **origin_country_region_id** هو سجل على مستوى الولاية أو البلدية على التوالي. إذا كنت ترغب في الحصول على بيانات أكثر تفصيلاً، يرجى الاتصال بنا ويمكننا مناقشة حالة استخدامك.

يرجى قضاء بعض الوقت للتعرف على بنية بيانات متطلبات الدخول من خلال إلقاء نظرة على وثائق واجهة برمجة التطبيقات (API) الخاصة بنا هنا.

جزء قد يكون محيرًا بعض الشيء في بنية البيانات هو استخدامنا لمصطلح “origin” (المصدر). هذا محير لأن المطورين غالبًا ما يفكرون في “المصدر” على أنه مكان المنشأ أو مكان المغادرة. ومع ذلك، ما نعنيه بالمصدر هو في الواقع مصدر القاعدة التي تُفرض على الآخرين. أي الدولة أو المنطقة التي أنشأت القيد.

نقطة مهمة أخرى يجب ملاحظتها هي كيفية عمل قائمة الدول المتأثرة لدينا. إذا كانت القائمة affected_countries فارغة، فيجب تفسير ذلك على أنه قاعدة عالمية. أي أن جميع الدول متأثرة.

بعض الأمثلة

كما رأيت على الأرجح من الوثائق، هناك عدة طرق لاسترداد البيانات من واجهة برمجة التطبيقات (API). أدناه سنستعرض بعض حالات الاستخدام الأكثر شيوعًا.

كيف يمكنني جلب المتطلبات بين دولتين؟

هناك طريقتان للقيام بهذا النوع من الطلبات. أبسط نسخة هي استخدام معلمتي **destination** و **departure**. تقبل هاتان المعلمتان رموز ISO 3166-1 alpha-2 كمدخلات.

GET https://www.sitata.com/api/v2/entry_requirements?departure=DE&destination=IN

سيتضمن الرد جميع المتطلبات (على مستوى الدولة والولاية) اللازمة لفهمها للمسافر المغادر من دولة المغادرة والمتجه إلى دولة الوجهة.

ماذا لو أردت بيانات على مستوى الولاية؟

تمتلك Sitata بيانات على مستوى الولاية لمناطق معينة. ستعرف أن إدخالًا معينًا خاص بولاية إذا كان للحقل origin_country_division قيمة. يمكنك أيضًا التصفية لاسترداد بيانات مستوى الولاية فقط باستخدام المعلمة **destination_country_division**. تتوقع هذه المعلمة قيمة ISO_3166-2. على سبيل المثال، US-TX لتكساس، الولايات المتحدة.

GET https://www.sitata.com/api/v2/entry_requirements?departure=DE&destination_country_division=IN-AP

لاحظ أنه قد يكون من الأبسط الاستعلام حسب الدولة ثم التصفية حسب بيانات الولاية لمعرفة ما إذا كانت هذه البيانات موجودة، واستخدامها إذا كانت موجودة بالفعل.

كيف يمكنني جلب المتطلبات بين مطارين؟

تمامًا كما هو الحال مع الدول، يمكن لواجهة برمجة تطبيقات Sitata إرجاع النتائج بين مطارين. تستخدم المعلمتان departure_airport و destination_airport إما رموز ICAO أو IATA لتصفية النتائج. سيتضمن الرد جميع القيود (على مستوى الدولة والولاية) اللازمة لفهمها للمسافر المغادر من دولة المغادرة المقابلة والمتجه إلى دولة الوجهة.

GET https://www.sitata.com/api/v2/entry_requirements?departure_airport=MUC&destination_airport=BOM

سيتضمن الرد جميع القيود (على مستوى الدولة والولاية) اللازمة لفهمها للمسافر المغادر من دولة المغادرة والمتجه إلى دولة الوجهة.

ماذا لو كانت لدي معلومات المدينة فقط؟

اختارت Sitata عدم استيعاب الاستعلامات باسم مدينة معينة لأن ذلك قد يؤدي إلى تعارضات وارتباك. بدلاً من ذلك، اخترنا استيعاب الاستعلام لواجهة برمجة التطبيقات (API) الخاصة بنا باستخدام إحداثيات خطوط الطول والعرض، مما لا ينتج عنه أي غموض في مجموعة نتائجنا. المعلمات هي departure_lat، departure_lng، destination_lat، و 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

إذا قمت بتحويل مدنك إلى مواقع واستعلمت بناءً على الإحداثيات، فسترد واجهة برمجة التطبيقات (API) الخاصة بنا بجميع القيود (على مستوى الدولة والولاية) اللازمة لفهمها للمسافر المغادر من دولة المغادرة والمتجه إلى دولة الوجهة.

بيانات إضافية

لأنواع معينة من متطلبات الدخول، قد تكون هناك بيانات إضافية مرتبطة في حقل من نوع البيانات الوصفية يسمى extras. هذا الحقل هو تعيين مفتاح/قيمة لمعلومات إضافية متنوعة لمتطلب معين.

ما هو عدد أيام الحجر الصحي؟

يأتي إدخال البيانات هذا تحت متطلب الدخول من النوع 5. في هذا الإدخال، سيتضمن تعيين **extras** حقلًا يسمى quarantine_days والذي سيحتوي على عدد صحيح يمثل عدد أيام الحجر الصحي المفروض.

ما هو عدد الساعات قبل الدخول لفحص كوفيد سلبي؟

يأتي إدخال البيانات هذا تحت متطلب الدخول من النوع 8. في هذا الإدخال، سيتضمن تعيين **extras** حقلًا يسمى entry_hours والذي سيحتوي على عدد صحيح يمثل عدد الساعات المسموح بها لفحص كوفيد سلبي قبل الدخول.

أخبرنا

نعتقد أن لدينا نظامًا قويًا جدًا من المرجح أن يلبي جميع احتياجاتك لمساعدة مسافريك على فهم ما من المحتمل أن يواجهوه على طول الطريق. إذا كان لديك حالة استخدام معينة لا نغطيها، يرجى إخبارنا!

انتظر… هناك المزيد!

هذا الإدخال هو جزء من سلسلة من جزأين تشرح كيفية التفاعل مع واجهة برمجة تطبيقات Sitata للحصول على معلومات متطلبات الدخول وقيود السفر. لقد تحدثنا حتى الآن عن متطلبات الدخول التي تحدد متطلبات “نعم/لا” الصارمة اللازمة لدخول دولة أو منطقة، لكننا لم نتحدث عما يحدث داخل الدولة أيضًا. معرفة إمكانية الدخول إلى دولة شيء، وفهم ما إذا كان من الممكن التحرك داخل الدولة أو زيارة الشواطئ أو إذا كان هناك حظر تجول إلزامي شيء آخر.

ترقبوا المنشور الثاني الذي سيغوص بعمق في مجموعة بيانات “قيود السفر” الخاصة بنا. تلميح - إنها متطابقة تقريبًا لذا يمكنك دائمًا إلقاء نظرة على وثائق واجهة برمجة التطبيقات (API) الخاصة بنا في غضون ذلك.