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

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

MS
Madeline Sharpe
|

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

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

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

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

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

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

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

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

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

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

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

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

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

جزء من بنية البيانات مربك قليلاً، وهو استخدامنا لمصطلح “origin”. يأتي هذا الارتباك من حقيقة أن المطورين غالبًا ما يعتبرون الأصل هو مكان المنشأ أو مكان المغادرة. ومع ذلك، ما نعنيه بـ “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. هذا الحقل هو تعيين مفتاح/قيمة لعناصر معلومات إضافية متنوعة لمتطلب معين.

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

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

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

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

أخبرنا

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

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

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

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

الوسوم
اختيار-المحررتكنولوجيا
MS
كتب بواسطة Madeline Sharpe