CreateBooking Ready, CreateBooking Ready

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

الزامات وظیفه CreateBooking

  • ۱۰ درخواست CreateBooking در Sandbox با نرخ موفقیت ۹۰٪ یا بالاتر.
  • ۳ درخواست CreateBooking در محیط عملیاتی با نرخ موفقیت ۹۰٪ یا بالاتر.

اصول اولیه CreateBooking

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

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

خودتوانی

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

  • CreateBooking
  • UpdateBooking

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

در زیر چند نمونه از نحوه مدیریت idempotency توسط سرورهای رزرواسیون آورده شده است:

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

الزام خودتوانی (idempotency) برای تمام متدهایی که حالت را تغییر می‌دهند، اعمال می‌شود.