4. Adım: Rezervasyon sunucusunu uygulayın

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

• Standart uygulama. Bu sayede İşlem Merkezi, kullanıcı adına sizinle randevu, rezervasyon ve ön rezervasyon oluşturabilir.

Korumalı alan ve üretim rezervasyon sunucularınıza 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, Google'ın rezervasyon sunucusu isteklerini HTTP üzerinden göndermesine olanak tanır.

Başlamak için Actions Center korumalı alanı ortamına bağlanabilen bir geliştirme veya korumalı alan rezervasyon sunucusu oluşturun. Yalnızca korumalı alan sunucusu tamamen test edildikten sonra üretim ortamına geçin.

Yöntemler

Her rezervasyon sunucusu türü için farklı bir API yöntemi grubu gerekir. İsteğe bağlı olarak, API uygulamasını başlatmak için hizmet tanımını proto biçiminde indirebilirsiniz. Aşağıdaki tablolarda her uygulamanın yöntemleri gösterilmekte ve hizmet prototipi biçimlerinin bağlantıları yer almaktadır.

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

Yöntem	HTTP İsteği
HealthCheck	GET /v3/HealthCheck/
BatchAvailabilityLookup	POST /v3/BatchAvailabilityLookup/
CreateBooking	POST /v3/CreateBooking/
UpdateBooking	POST /v3/UpdateBooking/
GetBookingStatus	POST /v3/GetBookingStatus/
ListBookings	POST /v3/ListBookings/

API kaynakları

Rezervasyon

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

• Yuva: Envanter yuvası.
• Rezervasyon: Envanter aralığı için randevu.

Akış: Rezervasyon oluşturma

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

Bir kullanıcı rezervasyon oluşturduğunda Google, kullanıcının adını, soyadını, telefon numarasını ve e-posta adresini size gönderir. İşlem Merkezi, kullanıcının hesabını sisteminizde arayamadığından bu rezervasyonun sizin açınızdan konuk olarak ödeme olarak ele alınması gerekir. Nihai 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 yapılan 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ı gerekir. Sunucunuzu ayarlamanıza yardımcı olması için Qualys SSL Server Test gibi herkese açık bir SSL/TLS doğrulama aracı kullanmanızı öneririz.

Google'ın rezervasyon sunucunuza göndereceği tüm isteklerin kimliği, HTTP temel kimlik doğrulaması kullanılarak doğrulanır. Rezervasyon sunucunuzun temel kimlik doğrulama kimlik bilgilerini (kullanıcı adı ve şifre) İş Ortağı Portalı'ndaki Rezervasyon Sunucusu Yapılandırması sayfasına girebilirsiniz. Şifreler altı ayda bir değiştirilmelidir.

Ö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 REST yöntemleri stub'lenmiştir.

Şartlar

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

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

• Altyapıyla veya yanlış verilerle ilgili hatalar
  • Bu hataları istemciye standart HTTP hata kodlarıyla döndürün. HTTP durum kodlarının tam listesini inceleyin.
• İşletme mantığıyla ilgili hatalar
  • 200 OK 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ığı hatası türleri, farklı sunucu uygulama türleri için farklıdır.

Standart uygulamada, 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şturulurken veya güncellenirken iş mantığı hatalarıyla karşılaşılabilir. Örneğin, CreateBooking veya UpdatingBooking yöntemlerini işlediğinizde. Aşağıda bazı örnekler verilmiştir, ancak liste bunlarla sınırlı değildir:

• İstenen zaman aralığı artık kullanılamıyorsa SLOT_UNAVAILABLE kullanılır.
• Sağlanan kredi kartı türü kabul edilmezse PAYMENT_ERROR_CARD_TYPE_REJECTED kullanılır.

Tekilleştirme

Ağ üzerinden iletişim her zaman güvenilir değildir ve Google, yanıt alınmazsa HTTP isteklerini yeniden deneyebilir. Bu nedenle, durumu değiştiren tüm yöntemler idempotent olmalıdır:

• CreateBooking
• UpdateBooking

UpdateBooking hariç her istek mesajında, isteği benzersiz şekilde tanımlamak için tekilleştirme jetonları eklenir. Bu sayede, tek bir istek oluşturma amacıyla yeniden denenen bir REST çağrısını iki ayrı istek arasında ayırt edebilirsiniz. UpdateBooking, sırasıyla rezervasyon girişi kimliklerine göre benzersiz şekilde tanımlandığından isteklerine tekilleştirme jetonu dahil edilmez.

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

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

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

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