Customisation retour API (POST)

Customisation retour API (POST)
0
Tags: #<Tag:0x00007f5e53ce4a88>

Bonjour,
J’aurais besoin de remplacer le contenu (voir même le code retour) d’un appel API.
Nous avons 2 cas de figure :

  • Appel via Apigee qui requiert des messages formatés (sinon ils sont remplacés par une erreur standart peu explicite)
  • Appel via un hook d’une API Rest tierce. Dans ce cas on souhaiterai remplacé le contenu du retour Simplicite par celui de l’API tierce.

Merci par avance

J’avoue ne pas bien comprendre votre besoin:

  • De quelles “APIs” parlez vous exactement ?
  • Quel est le format des “messages formatés” attendus par Apigee ? Et dans quel(s) cas sont ils requis ? En quoi les réponses actuelles des APIs ne conviennent pas ?
  • Quel est le flow d’appel dans votre cas de “hook d’une API tierce” ?
    Etc
  • Je parle des APIs mappées.
  • Le message d’erreur, pour être accepté par Apigee, doit respecter un format JSON spécifique.
  • Pour le flow d’appel, je me place dans le hook preValidate afin d’intercepter l’appel (POST) et de récupérer les paramètres fournis. Puis, j’utilise ces paramètres pour appeler (toujours depuis ce hook) l’API tierce. Je récupère ainsi le résultat au format JSON (cette API utilise un POST mais fonctionne comme un GET…) et je souhaiterai placer ce résultat comme retour de mon API mappée.

Le message d’erreur, pour être accepté par Apigee, doit respecter un format JSON spécifique.

La classe des APIs mappées a été développée pour vous, et pour le moment vous êtes les seuls à l’utiliser, on peut donc modifier la manière dont sont générés les messages d’erreur pour se conformer à ce qu’attend votre Apigee.

Cela dit, le format actuel est, sauf erreur de notre part, celui décrit dans vos spécification “5 étoiles”. Si le format attendu par Apigee n’est pas le même j’avoue ne pas savoir ce qu’il convient de faire…

Pour le flow d’appel, je me place dans le hook preValidate afin d’intercepter l’appel (POST) et de récupérer les paramètres fournis. Puis, j’utilise ces paramètres pour appeler (toujours depuis ce hook) l’API tierce. Je récupère ainsi le résultat au format JSON (cette API utilise un POST mais fonctionne comme un GET…) et je souhaiterai placer ce résultat comme retour de mon API mappée

Merci de décrire plus précisément le début du flow car j’ai besoin de comprendre comment on arrive dans le preValidate de votre objet. Est-ce par un appel POST (creation) de l’API mappée de votre objet métier ?

En quoi ce qui est retourné par l’API tierce diffère de ce qui est retourné en standard par l’API mappée ?

Quid de la compliance avec vos normes “5 étoiles” si ce qui est retourné par cette API n’est pas conforme ? Quid de la complétude des informations retournées ? Etc.

Ne serait il pas possible de plutôt configurer un attribut texte long (rendering JSON) non persistant sur votre objet et d’y valoriser la réponse de votre API tierce, comme ça on conserverait la mécanique standard des APIs mappées (et la compliance “5 étoiles”) tout en fournissant la réponse brute de cette API tierce ?

Bonjour Thomas, David,

le schéma d’erreur documenté dans le swagger généré est conforme au design guide:
(extrait du design guide en ligne à ce jour):

{
 "errors": [ {
   "errorCode": "1234",                                                                                     (mandatory)
   "errorMessage": "Error message for users. This message will be displayed Web or App if required.",       (mandatory)
   "errorLevel" : {info, warning, error, critical},                                                         (recommended)
   "errorType" : {functional, technical},                                                                   (optional)
   "documentationUrl": "https://developer.{renault/nissan}.com/errors/1234" },                              (optional)
   "tips": "helpful message to adress" }                                                                    (optional)
  … ] } 
}

Test de conso de ressource inexistante:

{
 "errors": [ {
   "errorMessage":"No BCSILegalEntity record found for row ID 9999",
   "errorCode":"404",
   "errorLevel":"error"
 } ]
}

Ce qui est donc produit par le plateforme (doc+runtime) ne pose pas de problème.
Nous allons investiguer en interne pour déterminer à quel moment le message d’erreur est perdu/écrasé.

@ThomasB, le problème ne serait-il pas plutôt de savoir comment faire suivre un message d’erreur “fonctionnel” généré lors d’une opération sur un objet métier dans la structure retournée par l’api (via l’api mappée) ?

Bruno