Serveur partenaire

Pour intégrer les informations sur les prix et la disponibilité, les partenaires doivent implémenter l'API Partner. Cette interface est basée sur REST et permet à Google d'envoyer des appels en direct via HTTP. Les détails des méthodes d'API individuelles sont décrits dans la section Référence. Vous trouverez des informations sur les problèmes transversaux plus loin.

Format de requête et de réponse

Au départ, seuls les formats JSON seront acceptés. Si vous avez besoin d'autres formats de requête ou de réponse sont requis, contactez l'équipe Travel Transport à l'adresse [e-mail] pour discuter de votre cas d'utilisation.

Les requêtes seront envoyées à l'aide de la méthode HTTP POST, avec le message de requête dans le corps POST.

Notez que, pour plus de clarté structurelle, la documentation de l'interface API est fournie sous forme de définitions de messages Protocol Buffer. La traduction d'une définition de message Protocol Buffer en objet JSON est définie par le mappage JSON canonique, à l'aide des options permettant d'émettre des champs avec des valeurs par défaut et d'utiliser des noms de champs proto au lieu de noms en minuscules avec majuscules en début de mot.

Important : Nous vous recommandons d'utiliser les bibliothèques Protocol Buffer et les utilitaires JsonFormat inclus pour des API de type sécurisé qui garantissent la production de réponses syntaxiquement correctes. Les définitions d'énumérations présentées dans la documentation excluent la UNSPECIFIED valeur. Vous devez les ajouter lorsque vous utilisez directement des Protocol Buffers.

Authentification

Google est compatible avec l'authentification Digest HTTP, OAuth 2.0 et l'authentification par certificat client (voir Configuration du partenaire). Les partenaires doivent fournir à Google les identifiants appropriés lors des tests d'API :

• Pour Digest : nom d'utilisateur et mot de passe.
• Pour OAuth 2.0 : client_id et client_secret.
• Pour le certificat : un certificat client SSL.

Codes d'état et gestion des erreurs

En général, les codes d'état suivants peuvent être renvoyés dans les réponses HTTP :

HTTP Code	Description HTTP	Remarques
2xx	OK	Pas une erreur, affiché en cas de réussite. Le corps de la réponse doit contenir un résultat positif (par exemple, TripOptionsResult) et non une réponse d'erreur.
400	Requête incorrecte	La requête reçue n'était pas valide. Les réponses d'erreur spécifiques à la méthode doivent être utilisées pour renvoyer des détails d'erreur supplémentaires dans le corps de la réponse. Le code HTTP 400 ne doit généralement être utilisé que si Google a commis une erreur technique (par exemple, un champ mal nommé dans une requête).
403	Interdit	Autorisation refusée/interdite (l'appelant est connu et refusé). Cette réponse ne doit pas être utilisée pour les refus dus à l'épuisement d'une ressource (utilisez plutôt Trop de demandes dans ce cas). Interdit ne doit pas être utilisé si l'appelant ne peut pas être identifié (utilisez plutôt Non autorisé dans ce cas).
404	Introuvable	La ressource demandée est introuvable. Les réponses d'erreur spécifiques à la méthode doivent être utilisées pour renvoyer des détails d'erreur supplémentaires dans le corps de la réponse.
429	Trop de demandes	Certaines ressources ont été épuisées, par exemple un quota par utilisateur.
500	Erreur interne du serveur	Erreurs internes. Cela signifie que certains invariants attendus par le système sous-jacent n'ont pas été respectés. Ce code d'erreur est réservé aux erreurs graves et indique un bug dans l'implémentation du serveur d'API du partenaire.
503	Service indisponible	Le service est indisponible. Il s'agit probablement d'une condition temporaire qui peut être corrigée en réessayant après avoir laissé passer un intervalle entre les tentatives.
504	Expiration du délai de la passerelle	Le délai a expiré avant que l'opération puisse se terminer. Pour les opérations qui modifient l'état du système, cette erreur peut être affichée même si l'opération s'est terminée avec succès. Par exemple, une réponse réussie d'un serveur aurait pu être retardée suffisamment longtemps pour que le délai expire.

Notez que pour toutes les conditions préalables, les arguments non valides ou les erreurs "Introuvable" :

• les réponses ou messages d'erreur spécifiques à la méthode définis dans les API doivent être utilisés.
• le code HTTP approprié doit être utilisé, comme spécifié dans les codes spécifiques à la méthode (voir, par exemple, TripOptionsErrorType).

Cela permet de fournir des informations plus détaillées sur ces types d'erreurs. Ces informations peuvent être utilisées pour :

• Déterminer si une erreur peut être réessayée
  • SEGMENT_KEY_NOT_FOUND ne peut pas être réessayée.
• Corriger les informations obsolètes
  • Unavailable.Reason.CANCELED indique que le voyage doit être supprimé (notez que cela fait partie d'une réponse réussie).
  • Unavailable.Reason.TEMPORARILY_UNAVAILABLE , ainsi que les codes d'erreur SEGMENT_KEY_NOT_FOUND, SUBOPTIMAL_ITINERARY, BOOKING_WINDOW_NOT_SUPPORTED et TICKETING_PROHIBITED, suppriment tous les prix que nous avons précédemment reçus du cache.
• Fournir des conseils pertinents aux utilisateurs

La liste actuelle des erreurs spécifiques à la méthode fournie dans TripOptionsError est un point de départ. Si vous avez besoin d'autres types d'erreurs, veuillez contacter l'équipe Google Travel Transport.

RPS (requêtes par seconde)

Le niveau de RPS envoyé par Google est susceptible de varier en fonction de l'inventaire du partenaire et du nombre d'utilisateurs qui consultent les données mises en cache ou qui cliquent sur les sites Web des partenaires pour effectuer une réservation.

Latence

Les requêtes expireront au bout de 10 secondes. Aucune consigne de latence supplémentaire ne sera appliquée aux intégrations de partenaires bêta. Toutefois, d'autres objectifs de niveau de service de latence seront définis dans nos consignes concernant la qualité des données des partenaires.

Devises, taxes et frais

Tous les prix envoyés à Google doivent inclure toutes les taxes et tous les frais, et être spécifiés dans une devise acceptée.

Devise

La devise d'un prix est spécifiée à l'aide du currency_code champ, qui doit être un code de devise ISO 4217 valide.

Exemple : 10,25 USD

{
  "price": {
    "currency_code": "USD",
    "units": 10,
    "nanos": 250000000
  }
}

Taxes et frais

Le prix que vous fournissez doit être le prix total final que l'utilisateur paiera, y compris toutes les taxes (comme la TVA) et tous les frais supplémentaires (comme les frais de réservation ou de carte de paiement). Une ventilation facultative du tarif peut être ajoutée à l'aide du champ line_items répétable. Google affichera le prix total avec une ventilation facultative du tarif à l'utilisateur.