4. Adım: Rezervasyon sunucusunu uygulayın

Actions Center'ın sizin adınıza rezervasyon oluşturmak ve güncellemek amacıyla geri aramalar yapmasına izin vermek için bir rezervasyon sunucusu oluşturmanız gerekir.

• Standart uygulama. Bu sayede Actions Center, kullanıcı adına sizinle randevu, rezervasyon ve rezervasyon oluşturabilir.

Korumalı alan ve üretim rezervasyon sunucularınızla bağlantıyı nasıl yapılandıracağınızı öğrenmek için İş Ortağı Portalı belgelerine bakın.

REST API arayüzü uygulama

REST'e dayalı bir API arayüzü uygulayın. Bu sayede Google, HTTP üzerinden rezervasyon sunucusu istekleri gönderebilir.

Başlamak için Actions Center korumalı alan ortamına bağlanabilecek bir geliştirme veya korumalı alan rezervasyon sunucusu oluşturun. Korumalı alan sunucusu tam olarak test edildikten sonra yalnızca üretim ortamına geçin.

Yöntemler

Her rezervasyon sunucusu türü için farklı bir API yöntemi grubu oluşturmanız gerekir. İsteğe bağlı olarak, API uygulamasını kullanmaya başlamak için hizmet tanımını proto biçiminde indirebilirsiniz. Aşağıdaki tablolarda her bir uygulama için yöntemler gösterilmiştir ve hizmet protokolü biçimlerine bağlantılar verilmiştir.

Standart uygulama
Standart hizmet tanımı Proto hizmet tanımı dosyasını indirin.

Yöntem	HTTP İsteği
HealthCheck	İNDİRİN /v3/HealthCheck/
BatchAvailabilityLookup	POST /v3/BatchAvailabilityLookup/
CreateBooking	POST /v3/CreateReservation/
UpdateBooking	POST /v3/UpdateReservation/
GetBookingStatus	POST /v3/GetReservationStatus/
ListBookings	POST /v3/ListReservations/

API kaynakları

Rezervasyon

Standart uygulamada aşağıdaki kaynak türleri kullanılır:

• Alan: Envanter alanı.
• Rezervasyon: Envanter aralığı için randevu.

Akış: rezervasyon oluşturun

Bu bölümde, standart uygulama için rezervasyon oluşturma işlemi açıklanmaktadır.

Şekil 1: Slot'tan rezervasyon oluşturma iş akışı

Bir kullanıcı rezervasyon oluşturduğunda Google size kullanıcının adını, soyadını, telefon numarasını ve e-posta adresini gönderir. Actions Center, sisteminizde kullanıcının hesabını göremediğinden, sizin açınızdan bu rezervasyonun giriş yapmadan ödeme olarak değerlendirilmesi gerekir. Son rezervasyonun, satıcılarınızın rezervasyon sisteminizden gelen rezervasyonlarıyla aynı göründüğünden emin olun.

Güvenlik ve Kimlik Doğrulama

Rezervasyon sunucunuzla tüm iletişim HTTPS üzerinden gerçekleşir. Bu nedenle sunucunuzun, DNS adıyla eşleşen geçerli bir TLS sertifikasına sahip olması önemlidir. Sunucunuzu ayarlamak için Qualys' SSL Server Test gibi herkese açık bir SSL/TLS doğrulama aracını kullanmanızı öneririz.

Google'ın rezervasyon sunucunuza yapacağı tüm isteklerin kimliği, HTTP temel kimlik doğrulaması kullanılarak doğrulanır. Rezervasyon sunucunuzun temel kimlik doğrulama kimlik bilgileri (kullanıcı adı ve şifre), İş Ortağı Portalı'ndaki Rezervasyon Sunucusu Yapılandırma sayfasına girilebilir. Şifreler altı ayda bir döndürülmelidir.

Not: Korumalı Alan ve Üretim için kullanıcı adı ve şifreyi, Ortam değiştiriciyi kullanarak ayrı ayrı ayarlamanız gerekir.

Örnek İskelet Uygulamaları

Başlamak için Node.js ve Java çerçeveleri için yazılmış bir rezervasyon sunucusunun aşağıdaki örnek iskeletlerine göz atın:

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

Bu sunucularda sökük REST yöntemleri bulunur.

Koşullar

HTTP hataları ve iş mantığı hataları

Arka ucunuz HTTP isteklerini işlediğinde iki tür hata oluşabilir.

• Altyapı veya yanlış verilerle ilgili hatalar
  • Bu hataları, standart HTTP hata kodlarıyla istemciye döndürün. Tam HTTP durum kodu listesine bakın.
• İş mantığıyla ilgili hatalar
  • 200 Tamam olarak ayarlanmış HTTP durum kodunu döndürün ve yanıt gövdesinde iş mantığı hatasını belirtin. Karşılaşabileceğiniz iş mantığı hatalarının türleri, farklı sunucu uygulaması türleri için farklıdır.

Standart uygulama için olası iş mantığı hataları, Rezervasyon Hatası bölümünde yakalanır ve HTTP yanıtında döndürülür. Bir kaynak oluşturulduğunda veya güncellendiğinde iş mantığı hatalarıyla karşılaşabilirsiniz. Örneğin, CreateBooking veya UpdatingBooking yöntemlerini yönetirken. Aşağıda bazı örnekler verilmiştir, ancak liste bunlarla sınırlı değildir:

• İstenen alan artık mevcut değilse SLOT_UNAVAILABLE kullanılır.
• Sağlanan kredi kartı türü kabul edilmezse PAYMENT_ERROR_CARD_TYPE_REJECTED kullanılır.

Boşta kalma

Ağ üzerinden iletişim her zaman güvenilir değildir ve Google, yanıt alınmadığı takdirde HTTP isteklerini yeniden deneyebilir. Bu nedenle, mutasyon durumundaki tüm yöntemler eş potansiyelli olmalıdır:

• CreateBooking
• UpdateBooking

UpdateBooking dışındaki her istek mesajında, isteği benzersiz bir şekilde tanımlamak amacıyla cinsel gücü jetonları eklenir. Bu sayede, tek bir istek oluşturma amacı taşıyan yeniden denenen REST çağrısı ile iki ayrı isteği birbirinden ayırt edebilirsiniz. UpdateBooking, sırasıyla rezervasyon giriş kimlikleriyle benzersiz bir şekilde tanımlanır. Bu nedenle, isteklerine acil durum jetonu dahil edilmez.

Aşağıda, rezervasyon sunucularının aciliyeti nasıl ele aldığına dair bazı örnekler verilmiştir:

• Başarılı bir CreateBooking HTTP yanıtı, oluşturulan rezervasyonu içeriyor. Bazı durumlarda ödeme, rezervasyon akışının bir parçası olarak işlenir. Tam olarak aynı CreateBookingRequest ikinci kez alınırsa (aynı idempotency_token ile) aynı CreateBookingResponse döndürülmelidir. İkinci rezervasyon oluşturulmaz ve mümkünse kullanıcıdan tam olarak bir kez ödeme alınır.

  Bir CreateBooking denemesi başarısız olursa ve aynı istek yeniden gönderilirse arka ucunuzun bu durumda isteği yeniden denemesi gerektiğini unutmayın.

Aciliyet koşulu, durumu değiştiren tüm yöntemler için geçerlidir.