Serveur partenaire

Pour intégrer les informations sur les tarifs et la disponibilité, les partenaires devront 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 des requêtes et des réponses

Dans un premier temps, seuls les formats JSON seront acceptés. Si vous avez besoin d'autres formats de requête ou de réponse, 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 la requête dans le corps POST.

Notez que, pour plus de clarté, 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 lowerCamelCase.

Important : Il est recommandé d'utiliser les bibliothèques Protocol Buffers 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ération affichées dans la documentation excluent la valeur UNSPECIFIED. Vous devez les ajouter lorsque vous utilisez directement des fichiers .proto.

Authentification

Google est compatible avec l'authentification HTTP Digest et l'authentification par certificat client. Tous les appels HTTP de l'API Partner utilisent l'authentification HTTP Digest (avec nom d'utilisateur et mot de passe) ou l'authentification par certificat client. Le partenaire doit fournir à Google un nom d'utilisateur et un mot de passe (voir Configuration du partenaire) ou un certificat client SSL, respectivement.

Codes d'état et gestion des erreurs

En règle générale, 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 demande reçue n'était pas valide. Les réponses d'erreur spécifiques à la méthode doivent être utilisées pour renvoyer des informations supplémentaires sur l'erreur 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 requêtes" dans ce cas). Forbidden ne doit pas être utilisé si l'appelant ne peut pas être identifié (utilisez plutôt Unauthorized pour ces erreurs).
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 informations supplémentaires sur l'erreur 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 renvoyé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 correct 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
  • Il n'est pas possible de réessayer SEGMENT_KEY_NOT_FOUND.
• Corriger les informations obsolètes
  • Unavailable.Reason.CANCELED indique que le trajet doit être supprimé (notez que cela fait partie d'une réponse positive).
  • 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 reçus précédemment 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 requêtes par seconde envoyées 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 cliquent pour accéder aux sites Web des partenaires afin d'effectuer une réservation.

Latence

Les requêtes expirent au bout de 10 secondes. Aucune autre consigne de latence ne s'appliquera aux intégrations de partenaires en version bêta. Toutefois, d'autres SLO de latence seront définis dans nos consignes relatives à la qualité des données des partenaires.

Devises, taxes et frais

Tous les prix envoyés à Google doivent inclure l'ensemble des taxes et des frais, et être indiqués dans une devise acceptée.

Devise

La devise d'un prix est spécifiée à l'aide du champ currency_code, 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). Vous pouvez ajouter une répartition des tarifs facultative à l'aide du champ line_items répétable. Google affichera le prix total avec une répartition facultative des tarifs à l'utilisateur.