Rezervasyon sunucusunu uygulama

Google ile Rezervasyon'un sizin adınıza rezervasyon oluşturup güncellemesini sağlamak için bir rezervasyon sunucusu olmanız gerekir.

  • Standart uygulama. Böylece Google ile Rezervasyon, kullanıcı adına sizden randevular, rezervasyonlar ve rezervasyonlar 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ı belgelerini inceleyin.

REST API arayüzü uygulayın

REST'e dayalı bir API arayüzü uygulayın. Böylece Google, rezervasyon sunucusu isteklerini HTTP üzerinden gönderebilir.

Başlamak için Google ile Rezervasyon korumalı alan ortamına bağlanabilecek bir geliştirme veya korumalı alan rezervasyon sunucusu ayarlayın. Yalnızca korumalı alan sunucusu tam olarak test edildikten sonra üretim ortamına geçin.

Yöntemler

Her rezervasyon sunucusu türü için sizin farklı bir API yöntemi grubu 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 yöntemleri gösterilmektedir ve hizmet protokolü biçimlerinin bağlantıları verilmiştir.

Standart uygulama
Standart hizmet tanımı Proto hizmet tanımı dosyasını indirin.
Yöntem HTTP İsteği
Durum Denetimi /v3/HealthCheck/ ALIN
TopluMüsaitlikAraması POST /v3/BatchavailabilityLookup/
CreateBooking POST /v3/CreateBooking/
Güncelleme Rezervasyonu POST /v3/UpdateBooking/
GetBookingDurumu POST /v3/GetBookingStatus/
Liste Rezervasyonları POST /v3/ListBookings/

API kaynakları

Rezervasyon

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

  • Alan: Bir envanter alanı.
  • Rezervasyon: Envanter alanı için bir randevu.

Akış: Rezervasyon oluşturma

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

Şekil 1: Yuvadan rezervasyon oluşturma iş akışı
Şekil 1: Yuvadan 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-postasını gönderir. Google'da Rezervasyon, sisteminizde kullanıcının hesabını arayamaz. Bu nedenle, rezervasyonunuz bir misafir tarafından ödeme olarak kabul edilmelidir. Son rezervasyonun, satıcı sisteminizden gelen rezervasyonlarınızla aynı göründüğünden emin olun. Ücretsiz rezervasyonlar için giriş yapmadan ödeme ve alternatif e-posta adresleri varsayılan olarak desteklenir.

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ı önemlidir. Sunucunuzun ayarlanmasına yardımcı olmak için Qualys'in SSL Sunucu Testi gibi herkesin kullanımına açık bir SSL/TLS doğrulama aracı kullanmanızı öneririz.

Google'ın rezervasyon sunucunuza yapacağı tüm istekler, HTTP temel kimlik doğrulaması kullanılarak doğrulanır. Rezervasyon sunucunuz için 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.

Örnek İskelet Uygulamaları

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

Bu sunucular REST yöntemlerini kullanımdan kaldırdı.

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
  • İş mantığıyla ilgili hatalar
    • HTTP durum kodunu 200 Tamam olarak 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 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şılabilir. Örneğin, CreateBooking veya UpdatingBooking yöntemlerini ele aldığınızda. İlgili örnekler aşağıdakileri kapsar, ancak 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.

Geçersizlik

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

  • CreateBooking
  • UpdateBooking

UpdateBooking dışındaki her istek mesajında, kimliği benzersiz bir şekilde tanımlamak için kimlik jetonları eklenir. Bu sayede tek bir istek oluşturup iki ayrı istek oluşturmak amacıyla yeniden denenen REST çağrısını birbirinden ayırt edebilirsiniz. UpdateBooking, sırasıyla rezervasyon giriş kimlikleriyle benzersiz olarak tanımlanır. Bu nedenle, isteklerine kimlik jetonu dahil edilmez.

Aşağıda, rezervasyon sunucularının kimliği yönetme şekliyle ilgili bazı örnekler verilmiştir:

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

    Bir CreateBooking girişimi başarısız olursa ve aynı istek yeniden gönderilirse arka ucun bu durumda tekrar denemesi gerektiğini unutmayın.

Kimlik gerekliliği, durumu değiştiren tüm yöntemler için geçerlidir.