هر آژانسی که میخواهد موجودی هتل یا پرواز را روی سایتش نشان بدهد، دیر یا زود به یک عبارت میرسد: وب سرویس رزرو هتل و پرواز. تأمینکننده میگوید «مستندات وب سرویس را میفرستیم»، و از آن لحظه پروژه وارد فازی میشود که سوءتفاهم و هزینهٔ پنهان در آن زیاد است.
این مقاله یک راهنمای فنی اما قابلفهم است برای مدیران و تیمهای فنی آژانسها: وب سرویس در صنعت سفر دقیقاً چیست، چرخهٔ عمر یک رزرو در آن چطور طی میشود، و آن هفت مسئلهای که فقط بعد از اتصال واقعی معلوم میشوند کداماند.
وب سرویس در صنعت گردشگری یعنی چه
وب سرویس یک درگاه ماشینبهماشین است: سامانهٔ شما درخواستی میفرستد و سامانهٔ تأمینکننده پاسخی ساختاریافته برمیگرداند، بدون اینکه هیچ انسانی وسط باشد. اگر با مفهوم کلی API آشنا نیستید، پیشنهاد میکنیم اول راهنمای جامع API را بخوانید؛ این مقاله از آنجا شروع میکند و مخصوص صنعت سفر ادامه میدهد.
تفاوت مهم این حوزه با بقیهٔ صنایع در سه چیز است: داده سریع فاسد میشود (نرخ و ظرفیت ممکن است در چند دقیقه عوض شود)، عملیات پولی است (یک رزرو اشتباه یعنی ضرر مالی مستقیم) و هیچوقت فقط یک تأمینکننده ندارید (باید نتایج چند منبع را کنار هم بگذارید).
انواع تأمینکننده: داخلی و خارجی
وب سرویس هتل داخلی و پرواز داخلی
در بازار ایران معمولاً با این دستهها روبهرو میشوید:
- سامانههای پرواز داخلی: سرویسهایی که موجودی و نرخ پروازهای داخلی و گاهی خارجی را در اختیار آژانس میگذارند.
- عمدهفروشهای هتل داخلی: شرکتهایی که با هتلهای ایرانی قرارداد دارند و موجودی آنها را بهصورت وب سرویس ارائه میکنند.
- چارترکنندهها: ظرفیت بلوکهشدهٔ پرواز یا هتل که معمولاً قواعد کنسلی سختگیرانهتر و ساختار دادهٔ سادهتری دارد.
- سرویسهای جانبی: بیمهٔ مسافرتی، ترانسفر فرودگاهی، بلیت قطار و اتوبوس.
وب سرویس هتل خارجی: GDS، بدبانک و NDC
برای موجودی بینالمللی معمولاً با این مفاهیم سروکار پیدا میکنید:
- GDS: سامانههای توزیع جهانی مثل آمادئوس (Amadeus)، سیبر (Sabre) و تراولپورت (Travelport) که واسط سنتی بین ایرلاینها و آژانسها هستند.
- Bed Bank / تجمیعکنندهٔ هتل: شرکتهایی که موجودی هزاران هتل را یککاسه میکنند و یک API واحد میدهند.
- NDC: یک استاندارد دادهٔ مبتنی بر XML که خودِ یاتا تعریف کرده و مدل «Offer و Order» را جایگزین پیامهای سنتی EDIFACT میکند. برخلاف تصور رایج، NDC لزوماً بهمعنی «اتصال مستقیم به ایرلاین» نیست؛ همان محتوا را میتوان از طریق GDS یا تجمیعکننده هم گرفت. مزیت اصلیاش پوشش بهتر خدمات جانبی (بار اضافه، انتخاب صندلی) و قیمتگذاری شخصیسازیشده است.
نکتهٔ عملی: ساختار دادهٔ این دو دنیا شبیه هم نیست. سرویسهای داخلی معمولاً سادهتر و کممستندتر هستند و سرویسهای خارجی مفصلتر و سختگیرتر. اگر قرار است هر دو را داشته باشید، باید از روز اول یک لایهٔ میانی یکسانساز طراحی کنید که خروجی همهٔ تأمینکنندهها را به یک مدل داخلی واحد تبدیل کند؛ وگرنه منطق کسبوکارتان با شرطهای «اگر تأمینکننده الف بود...» پر میشود.
چرخهٔ عمر یک رزرو در وب سرویس رزرو هتل و پرواز
تقریباً همهٔ تأمینکنندهها، با نامهای متفاوت، همین پنج مرحله را دارند:
- ۱. جستوجو (Search): شما مقصد، تاریخ و ترکیب مسافر را میفرستید و فهرستی از گزینهها با قیمت تقریبی میگیرید. خروجی این مرحله تضمینشده نیست.
- ۲. بررسی مجدد ظرفیت و نرخ (Availability / Recheck): کاربر یک گزینه را انتخاب میکند و شما دقیقاً همان گزینه را دوباره استعلام میکنید. اینجاست که معلوم میشود قیمت عوض شده یا ظرفیت تمام شده است.
- ۳. پیشرزرو (PreBook / Quote): بعضی تأمینکنندهها امکان میدهند گزینه برای مدت کوتاهی رزرو موقت شود تا کاربر پرداخت را تمام کند.
- ۴. رزرو نهایی (Book): اطلاعات مسافران ارسال و رزرو قطعی میشود؛ خروجی معمولاً یک کد رزرو یا PNR است.
- ۵. صدور و سند (Ticket / Voucher): در بعضی سرویسها رزرو و صدور جدا هستند و بین این دو یک مهلت زمانی وجود دارد که اگر بگذرد رزرو باطل میشود.
و در کنار اینها، مسیر کنسلی و استرداد که تقریباً همیشه قواعد جداگانه و جریمهٔ پلکانی دارد.
چرا مرحلهٔ ۲ حذفشدنی نیست: بین لحظهای که کاربر نتیجه را دید و لحظهای که دکمهٔ پرداخت را زد، ممکن است دقایقی گذشته باشد. اگر بدون بررسی مجدد مستقیم به رزرو بروید، یا با خطای تأمینکننده مواجه میشوید یا بدتر: با قیمتی رزرو میکنید که از فروش شما بالاتر است و ضرر مستقیم میدهید.
هفت مسئلهای که فقط در عمل معلوم میشود
۱. تأخیر و صدا زدن همزمان چند تأمینکننده
اگر پنج منبع دارید و هر کدام بین یک تا هشت ثانیه جواب میدهند، نمیتوانید منتظر کندترین بمانید. راهحل استاندارد، تعریف یک بودجهٔ زمانی (مثلاً شش ثانیه) و نمایش نتایج جزئی است: هر تأمینکنندهای که در بودجه جواب داد نمایش داده میشود و بقیه بهصورت تدریجی اضافه میشوند. تجربهٔ کاربری «نتیجهٔ ناقص سریع» بهمراتب بهتر از «نتیجهٔ کامل دیرهنگام» است.
۲. چه چیزی را میشود کش کرد و چه چیزی را نه
این تفکیک، تفاوت یک سامانهٔ سریع و یک سامانهٔ کند است:
- قابل کش با عمر طولانی: اطلاعات ایستای هتل — نام، آدرس، مختصات، امکانات، تصاویر، توضیحات. اینها ماهها تغییر نمیکنند و باید یک بار گرفته و در دیتابیس خودتان ذخیره شوند.
- قابل کش با عمر بسیار کوتاه: نتایج جستوجو. چند دقیقه کش کردن جستوجوهای پرتکرار (مثلاً «تهران–مشهد، پنجشنبه») هم فشار روی تأمینکننده را کم میکند و هم سرعت را بالا میبرد.
- غیرقابل کش: نتیجهٔ بررسی مجدد پیش از پرداخت. این مرحله همیشه باید زنده باشد.
۳. محدودیت نرخ درخواست و سهمیه
تقریباً همهٔ تأمینکنندهها سقف تعداد درخواست دارند و بعضی حتی نسبت «جستوجو به رزرو» را رصد میکنند. اگر بیمحابا درخواست بفرستید، ممکن است موقتاً مسدود شوید. سه ابزار لازم دارید: صف برای کنترل نرخ خروجی، عقبنشینی نمایی در تلاش مجدد، و مدار شکن که وقتی یک تأمینکننده پیاپی خطا میدهد، مدتی از چرخه خارجش کند تا کل سامانه را کند نکند.
۴. نگاشت داده — دردسر ساکت پروژه
«هتل اسپیناس پالاس» در سرویس الف با کد ۱۲۳۴ و در سرویس ب با کد دیگری شناخته میشود، و در یکی «Espinas Palace» و در دیگری «Espinas Palace Hotel» نوشته شده است. اگر اینها را به هم نگاشت نکنید، کاربر یک هتل را دو بار با دو قیمت میبیند و به سامانهٔ شما اعتماد نمیکند. برای شهرها و فرودگاهها معمولاً کد IATA کمک میکند، اما برای هتلها باید یک جدول نگاشت داخلی بسازید و آن را با ترکیب نام، مختصات جغرافیایی و آدرس بهصورت نیمهخودکار پر کنید و بعد دستی تأیید کنید. برای بازار ایران یک لایهٔ اضافه هم دارید: نام فارسی و انگلیسی و املاهای مختلف یک نام.
۵. تکرارپذیری امن درخواست و حالت «نتیجهٔ نامعلوم»
خطرناکترین حالت ممکن این است: درخواست رزرو را فرستادهاید، تأمینکننده آن را ثبت کرده، اما پاسخ در راه گم شده یا زمانش تمام شده است. حالا شما نمیدانید رزرو انجام شده یا نه. اگر دوباره بفرستید، ممکن است دو رزرو ثبت شود و دو بار هزینه بدهید.
دو ابزار برای این حالت وجود دارد. اول کلید تکرارپذیری امن (Idempotency Key) — نامش «کلید یکتایی» نیست و معنایش هم یکتایی نیست؛ معنایش این است که تکرارِ یک درخواست اثر تازهای نسازد: کلیدی که همراه درخواست رزرو میفرستید تا اگر همان درخواست دوباره رسید، تأمینکننده بهجای ساختن رزرو دوم همان نتیجهٔ قبلی را برگرداند. دوم فرایند تطبیق (Reconciliation) که بهصورت دورهای رزروهای «نامعلوم» را با استعلام وضعیت از تأمینکننده تعیینتکلیف میکند. سامانهای که این دو را ندارد، در نهایت جایی پول از دست میدهد.
۶. پول: ارز، مارکآپ و مالیات
قیمتی که از تأمینکننده میگیرید قیمت فروش شما نیست. بین این دو چند لایه وجود دارد: نرخ تبدیل ارز (و اینکه با چه نرخی و در چه لحظهای قفل میشود)، مارکآپ یا کمیسیون شما، تخفیف کاربر، کمیسیون همکار و در نهایت مالیات و عوارض. اصل مهم این است که قیمت خرید و قیمت فروش را جداگانه ذخیره کنید؛ اگر فقط قیمت نهایی را نگه دارید، در اختلاف مالی با تأمینکننده هیچ سندی ندارید و حاشیهٔ سود واقعیتان را هم نمیتوانید گزارش بگیرید.
۷. تغییر وضعیت بعد از رزرو
پرواز کنسل میشود، ساعت عوض میشود، هتل اتاق را جابهجا میکند. بعضی تأمینکنندهها این تغییرات را با وبهوک اطلاع میدهند و بعضی هیچ اطلاعی نمیدهند و شما باید دورهای وضعیت رزروهای آینده را استعلام کنید. هر کدام که باشد، باید از قبل مشخص باشد چه کسی و چطور به مسافر خبر میدهد؛ این یک تصمیم عملیاتی است، نه فنی.
چه چیزی را باید حتماً ذخیره کنید
یک قاعدهٔ ساده که بعداً شما را نجات میدهد: هر درخواست و پاسخ مرتبط با پول را خام ذخیره کنید. یعنی متن کامل درخواست و پاسخ مرحلهٔ بررسی نرخ، رزرو و کنسلی، همراه با زمان دقیق و شناسهٔ تراکنش. حجم این داده در مقایسه با ارزشش ناچیز است. وقتی سه ماه بعد تأمینکننده میگوید «شما این نرخ را ندیدید»، این لاگ تنها سند شماست. توصیهٔ امنیتی: دادههای هویتی مسافر را در این لاگها پوشانده (masked) ذخیره کنید.
چه زمانی اصلاً به وب سرویس نیاز ندارید
اگر محصول شما تور خودتان است، ظرفیت را خودتان تعیین میکنید و قرارداد مستقیم با هتل دارید، اتصال به وب سرویس هیچ ارزشی اضافه نمیکند و فقط پیچیدگی میآورد. در این حالت آنچه لازم دارید یک سیستم رزرواسیون آنلاین با موجودی داخلی است، نه یک لایهٔ تجمیع تأمینکننده. بسیاری از آژانسها این دو را با هم اشتباه میگیرند و بودجه را جای اشتباه خرج میکنند.
چکلیست پیش از امضای قرارداد با تأمینکننده
- محیط تست (Sandbox) با اعتبارنامهٔ مستقل دارید یا باید روی محیط واقعی تست کنید؟
- مستندات بهروز است و نمونهٔ درخواست و پاسخ واقعی دارد؟
- سقف نرخ درخواست چقدر است و نسبت جستوجو به رزرو رصد میشود؟
- کلید Idempotency برای رزرو پشتیبانی میشود؟
- وبهوک تغییر وضعیت دارد یا باید استعلام دورهای بزنید؟
- قواعد کنسلی و استرداد در API برگردانده میشود یا باید در قرارداد بخوانید؟
- تعهد زمان پاسخگویی (SLA) و کانال پشتیبانی فنی چیست؟
- خروجی اطلاعات ایستا (فهرست هتلها، شهرها) بهصورت یکجا قابل دریافت است؟
- در صورت قطعی سرویس، مسئولیت رزروهای نیمهکاره با کیست؟
جمعبندی
اتصال به وب سرویس رزرو، بیشتر از آنکه مسئلهٔ «صدا زدن یک API» باشد، مسئلهٔ مدیریت عدم قطعیت است: دادهای که سریع کهنه میشود، سرویسی که ممکن است جواب ندهد، و پولی که نباید دوبار جابهجا شود. تیمی که این سه را از ابتدا در معماری ببیند، شانس بهمراتب بیشتری دارد که سامانهاش در روز شلوغ هم سرپا بماند.
ما در یوتا این لایه را برای سامانههای گردشگری با لاراول پیادهسازی میکنیم و اگر به تیم فنی و برنامه نویسی اختصاصی برای این کار نیاز دارید، جزئیات خدمات و پلنها در صفحهٔ طراحی سایت آژانس مسافرتی و سامانهٔ رزرو آمده است.
سؤالات متداول
تفاوت وب سرویس هتل داخلی و خارجی چیست؟
تفاوت اصلی در ساختار داده و انتظارات است. سرویسهای داخلی معمولاً سبکتر، کممستندتر و نزدیک به شرایط بازار ایران هستند؛ سرویسهای خارجی مفصلتر، استانداردتر و سختگیرتر در قواعد استفاده. اگر هر دو را دارید، حتماً یک لایهٔ یکسانساز بین آنها و منطق کسبوکارتان بگذارید.
چرا قیمت لحظهٔ جستوجو با قیمت لحظهٔ پرداخت فرق میکند؟
چون نتیجهٔ جستوجو یک تصویر لحظهای است و تضمینی نیست. نرخ و ظرفیت در فاصلهٔ چند دقیقه میتواند عوض شود. به همین دلیل مرحلهٔ بررسی مجدد پیش از پرداخت اجباری است و سامانه باید تفاوت قیمت را شفاف به کاربر نشان بدهد.
اتصال به یک وب سرویس چقدر زمان میبرد؟
اتصال اولیه و گرفتن نتیجهٔ جستوجو معمولاً سریع است. زمان اصلی صرف مسیر رزرو، مدیریت خطاها، نگاشت داده و آزمون سناریوهای واقعی میشود. تجربه نشان میدهد بخش عمدهٔ زمان پروژه به همین جزئیات میگذرد، نه به اولین تماس موفق.
آیا میشود چند تأمینکننده را همزمان روی سایت داشت؟
بله و در عمل معمولاً لازم است. اما به سه چیز نیاز دارید: یک مدل دادهٔ داخلی واحد، نگاشت درست هتلها و شهرها برای حذف نتایج تکراری، و منطق روشن برای انتخاب گزینهٔ نمایشدادهشده وقتی یک محصول از چند منبع با قیمت متفاوت میآید.
اگر تأمینکننده وبهوک نداشته باشد چه کنیم؟
باید استعلام دورهای بگذارید؛ معمولاً برای رزروهای نزدیک با فاصلهٔ کوتاهتر و برای رزروهای دور با فاصلهٔ بلندتر. مهم این است که این فرایند خودکار باشد و نتیجهاش بهصورت اعلان به تیم عملیات و به مسافر برسد.
