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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

بعض الأمثلة

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

كيف يمكنني الحصول على المتطلبات بين دولتين؟

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

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

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

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

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

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

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

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

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

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

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

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

أخبرونا

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

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

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

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