مرحله 3: سرور رزرو لیست انتظار را اجرا کنید

برای ایجاد و به‌روزرسانی رزروها از طرف شما، باید یک سرور رزرو راه‌اندازی کنید تا به مرکز اقدامات امکان برقراری تماس‌ها را بدهد.

• اجرای لیست انتظار رزروها. هنگامی که در برنامه آزمایشی لیست انتظار رزرو شرکت می کنید از این استفاده می شود. این به مرکز اقدامات اجازه می دهد تا تخمین های انتظار را بازیابی کند و ورودی های لیست انتظار را از طرف کاربر ایجاد کند.
• اجرای استاندارد این به مرکز اقدامات اجازه می دهد تا از طرف کاربر قرار ملاقات، رزرو و رزرو را با شما ایجاد کند. برای پیاده سازی سرور رزرو برای ادغام پایان به انتها رزرواسیون لطفاً به اجرای سرور رزرو مراجعه کنید.

برای آشنایی با نحوه پیکربندی اتصال به sandbox و سرورهای رزرو تولید، به مستندات پورتال شریک مراجعه کنید.

یک رابط REST API را پیاده سازی کنید

یک رابط API بر اساس REST پیاده سازی کنید این به Google اجازه می دهد درخواست های سرور رزرو را از طریق HTTP ارسال کند.

برای شروع، یک سرور رزرو توسعه یا جعبه ایمنی راه‌اندازی کنید که می‌تواند به محیط سندباکس مرکز اقدامات متصل شود. فقط زمانی که سرور سندباکس به طور کامل آزمایش شد، به محیط تولید بروید.

مواد و روش ها

برای هر نوع سرور رزرو، مجموعه متفاوتی از روش‌های API در انتهای شما مورد نیاز است. به صورت اختیاری، می‌توانید تعریف سرویس را در قالب پروتو دانلود کنید تا پیاده‌سازی API را شروع کنید. جداول زیر روش‌های هر پیاده‌سازی را نشان می‌دهد و شامل پیوندهایی به فرمت‌های پروتو سرویس است.

اجرای لیست انتظار
تعریف خدمات لیست انتظار فایل تعریف سرویس پروتو را دانلود کنید.

روش	درخواست HTTP
بررسی سلامت	دریافت /v3/HealthCheck/
BatchGetWaitEstimates	POST /v3/BatchGetWaitEstimates/
CreateWaitlist Entry	POST /v3/CreateWaitlistEntry/
GetWaitlistEntry	POST /v3/GetWaitlistEntry/
حذف Waitlist Entry	POST /v3/DeleteWaitlistEntry/

منابع API

لیست انتظار

منابع زیر برای اجرای رزرو مبتنی بر لیست انتظار استفاده می شود:

• WaitEstimate : تخمین انتظار برای اندازه حزب و تاجر خاص.
• WaitlistEntry : ورودی کاربر در لیست انتظار.

جریان: یک ورودی لیست انتظار ایجاد کنید

این بخش نحوه ایجاد رزرو برای ادغام لیست انتظار رزرواسیون را پوشش می دهد.

شکل 2: گردش کار برای ایجاد یک ورودی لیست انتظار

هنگامی که کاربر یک ورودی لیست انتظار ایجاد می کند، Google نام، نام خانوادگی، شماره تلفن و ایمیل کاربر را برای شما ارسال می کند. ایمیل همانند حساب کاربری گوگل کاربر است و به عنوان یک شناسه منحصر به فرد در نظر گرفته می شود. از دیدگاه شما، این لیست انتظار باید به عنوان یک تسویه حساب مهمان در نظر گرفته شود، زیرا رزرو با Google نمی تواند حساب کاربر را در سیستم شما جستجو کند. مطمئن شوید که ورودی نهایی فهرست انتظار با ورودی‌های تاجران شما که از سیستم فهرست انتظار شما می‌آیند، یکسان به نظر می‌رسد.

امنیت و احراز هویت

تمام ارتباطات با سرور رزرو شما از طریق HTTPS انجام می شود، بنابراین ضروری است که سرور شما دارای یک گواهی معتبر TLS باشد که با نام DNS آن مطابقت داشته باشد. برای کمک به راه‌اندازی سرور خود، استفاده از ابزار تأیید صحت SSL/TLS رایگان را توصیه می‌کنیم، مانند تست سرور SSL Qualys .

تمام درخواست‌هایی که Google به سرور رزرو شما می‌کند با استفاده از احراز هویت اولیه HTTP احراز هویت می‌شوند. اعتبارنامه های اصلی احراز هویت (نام کاربری و رمز عبور) برای سرور رزرو شما را می توان در صفحه پیکربندی سرور رزرو در پورتال شریک وارد کرد. پسوردها باید هر شش ماه یکبار چرخانده شوند.

توجه: شما باید نام کاربری و رمز عبور Sandbox و Production را با استفاده از Environment switcher به طور جداگانه تنظیم کنید.

نمونه پیاده سازی اسکلت

برای شروع، نمونه اسکلت های زیر را از یک سرور رزرو که برای Node.js و چارچوب های جاوا نوشته شده است، بررسی کنید:

• Node.js skeleton js-maps-booking-rest-server-v3-skeleton
• Java skeleton java-maps-booking-rest-server-v3-skeleton

این سرورها روش های REST را حذف کرده اند.

توجه: برای ادغام فهرست‌های انتظار رزرواسیون، روش‌های REST را به روش‌های فهرست انتظار رزروهای مورد نیاز تغییر دهید.

الزامات

خطاهای HTTP و خطاهای منطق تجاری

هنگامی که باطن شما درخواست های HTTP را مدیریت می کند، ممکن است دو نوع خطا رخ دهد.

• خطاهای مربوط به زیرساخت یا داده های نادرست
  • این خطاها را با کدهای خطای استاندارد HTTP به مشتری برگردانید. لیست کامل کد وضعیت HTTP را ببینید.
• خطاهای مربوط به منطق کسب و کار
  • کد وضعیت HTTP را روی 200 OK تنظیم کرده و خطای منطق تجاری را در بدنه پاسخ مشخص کنید. انواع خطاهای منطق تجاری که می توانید با آنها روبرو شوید برای انواع مختلف اجرای سرور متفاوت است.

برای ادغام فهرست‌های انتظار رزرواسیون، خطاهای منطق کسب‌وکار در Wiitlist Business Logic Failure ثبت می‌شوند و در پاسخ HTTP برگردانده می‌شوند. ممکن است هنگام ایجاد یک منبع، به عنوان مثال زمانی که روش CreateWaitlistEntry را مدیریت می کنید، با خطاهای منطق تجاری مواجه شوید. مثال‌ها شامل موارد زیر است، اما به آنها محدود نمی‌شود:

• ABOVE_MAX_PARTY_SIZE زمانی استفاده می‌شود که ورودی فهرست انتظار درخواستی بیش از حداکثر اندازه مهمانی تاجر باشد.
• MERCHANT_CLOSED زمانی استفاده می‌شود که فهرست انتظار باز نباشد زیرا تاجر قبلاً بسته شده است.

ناتوانی

ارتباط از طریق شبکه همیشه قابل اعتماد نیست و اگر پاسخی دریافت نشود، Google ممکن است درخواست‌های HTTP را دوباره امتحان کند. به همین دلیل، همه روش‌هایی که حالت جهش پیدا می‌کنند باید فاقد قدرت باشند:

• CreateWaitlistEntry
• DeleteWaitlistEntry

برای هر پیام درخواستی به جز DeleteWaitlistEntry ، نشانه‌های idempotency برای شناسایی منحصر به فرد درخواست گنجانده شده است. این به شما امکان می‌دهد بین یک تماس REST تکرار شده، با هدف ایجاد یک درخواست واحد، و دو درخواست جداگانه تمایز قائل شوید. DeleteWaitlistEntry به ترتیب توسط شناسه های ورودی لیست انتظار آنها به طور منحصر به فرد شناسایی می شود، بنابراین هیچ نشانه عدم توانایی در درخواست های آنها گنجانده نشده است.

در زیر چند نمونه از نحوه برخورد سرورهای رزرو با عدم توانایی ارائه شده است:

• یک پاسخ موفق CreateWaitlistEntry HTTP شامل شناسه ورودی لیست انتظار ایجاد شده است. اگر همان CreateWaitlistEntryRequest برای بار دوم دریافت شود (با همان idempotency_token )، همان CreateWaitlistEntryResponse باید برگردانده شود. هیچ ورودی لیست انتظار دوم ایجاد نمی شود و هیچ خطایی برگردانده نمی شود.

  توجه داشته باشید که اگر تلاش CreateWaitlistEntry با شکست مواجه شد و همان درخواست مجددا ارسال شد، باطن شما باید در این مورد دوباره امتحان کند.

شرط ناتوانی برای همه روش هایی که حالت جهش پیدا می کنند اعمال می شود.