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ışı](https://developers.google.cn/static/actions-center/images/rest_api_v3_booking_flow_1.png?authuser=7&hl=tr)
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.
Ö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.