مرحله 4: سرور رزرو را پیاده سازی کنید

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

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

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

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

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

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

مواد و روش ها

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

اجرای استاندارد
تعریف سرویس استاندارد فایل تعریف سرویس اولیه را دانلود کنید.

روش	درخواست HTTP
بررسی سلامت	دریافت /v3/HealthCheck/
BatchAvailabilityLookup	POST /v3/BatchAvailabilityLookup/
ایجاد رزرو	POST /v3/CreateBooking/
به روز رسانی رزرو	POST /v3/UpdateBooking/
GetBookingStatus	POST /v3/GetBookingStatus/
لیست رزرو	POST /v3/ListBookings/

منابع API

رزرو

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

• اسلات : یک شکاف موجودی.
• رزرو : یک قرار ملاقات برای یک اسلات موجودی.

جریان: ایجاد یک رزرو

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

شکل 1: گردش کار برای ایجاد یک رزرو از یک اسلات

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

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

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

تمام درخواست‌هایی که 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 را حذف کرده اند.

الزامات

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

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

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

برای اجرای استاندارد، خطاهای احتمالی منطق کسب و کار در Booking Failure ثبت می‌شوند و در پاسخ HTTP برگردانده می‌شوند. هنگام ایجاد یا به روز رسانی یک منبع ممکن است با خطاهای منطق تجاری مواجه شوید. به عنوان مثال، وقتی روش‌های CreateBooking یا UpdatingBooking را مدیریت می‌کنید. مثال‌ها شامل موارد زیر است، اما به آنها محدود نمی‌شود:

• اگر اسلات درخواستی دیگر در دسترس نباشد SLOT_UNAVAILABLE استفاده می‌شود.
• اگر نوع کارت اعتباری ارائه شده پذیرفته نشود، از PAYMENT_ERROR_CARD_TYPE_REJECTED استفاده می شود.

ناتوانی

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

• CreateBooking
• UpdateBooking

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

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

• یک پاسخ موفق CreateBooking HTTP شامل رزرو ایجاد شده است. در برخی موارد، پرداخت به عنوان بخشی از جریان رزرو پردازش می شود. اگر دقیقاً همان CreateBookingRequest برای بار دوم دریافت شود (با همان idempotency_token )، همان CreateBookingResponse باید برگردانده شود. هیچ رزرو دومی ایجاد نمی‌شود و در صورت وجود، دقیقاً یک بار از کاربر هزینه دریافت می‌شود.

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

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