CreateBooking Ready

Pour effectuer la tâche de jalon "Prêt" CreateBooking, vous devez créer et fournir la méthode CreateBooking. Cette méthode est appelée lorsqu'un utilisateur tente de créer une réservation. Si une réservation est créée, la réponse inclut un booking_id unique permettant de faire référence à la réservation pour les requêtes ou mises à jour futures.

Conditions requises pour la tâche CreateBooking

  • 10 requêtes CreateBooking dans le bac à sable avec un taux de réussite d'au moins 90 %.
  • 3 requêtes CreateBooking en production avec un taux de réussite d'au moins 90 %.

Principes de base de CreateBooking

Lorsqu'un utilisateur lance une réservation, une requête CreateBooking est envoyée au serveur de réservation du partenaire. La réponse à la requête indique si la réservation a réussi ou échoué. En cas d'échec, la réponse doit inclure l'erreur de logique métier correspondante. Par exemple, le créneau n'est plus disponible ou a déjà été réservé par le même utilisateur.

Lorsqu'un utilisateur crée une réservation, Google vous envoie son nom, son prénom, son numéro de téléphone et son adresse e-mail. Pour en savoir plus, consultez le règlement sur la mise en correspondance et la création de comptes.

Idempotence

La communication sur le réseau n'est pas toujours fiable. Google est susceptible de retenter l'envoi de requêtes HTTP si aucune réponse n'est reçue. Par conséquent, toutes les méthodes qui modifient l'état doivent être idempotentes :

  • CreateBooking
  • UpdateBooking

Pour que la requête soit identifiée de manière unique, des jetons d'idempotence sont inclus dans chaque message de requête, à l'exception de UpdateBooking. Cela vous permet de faire la distinction entre une nouvelle tentative d'appel REST (dont l'intention est de créer une seule requête) et l'envoi de deux requêtes distinctes. Les ID d'entrée de réservation respectifs de UpdateBooking permettent de les identifier de manière unique. Elles n'incluent donc aucun jeton d'idempotence.

Voici quelques exemples de la manière dont les serveurs de réservation gèrent l'idempotence :

  • Une réponse CreateBooking HTTP positive inclut la réservation créée. Dans certains cas, le paiement est traité pendant le processus de réservation. Si la même CreateBookingRequest est reçue une deuxième fois avec le même idempotency_token, c'est la même CreateBookingResponse qui doit alors être renvoyée. Une deuxième réservation n'est pas créée, et l'utilisateur n'est facturé qu'une seule fois (le cas échéant).

La condition d'idempotence s'applique à toutes les méthodes qui modifient l'état.