Open API et flux JSON

Thomas LEGAT · le 04/10/19 à 09:20

Bonjour,

Il est possible depuis la V10 d'avoir pour certains webservices, les données retournées en JSON au lieu du XML en mettant application/json en en-tête Accept.

Quand nous testons avec des extensions navigateurs il n'y a pas de soucis.

Dans un contexte JPlatform, nous avons l'habitude d'utiliser la classe HttpClientUtils pour faire les appels Http. Nous n'avons pas trouvé la possibilité de passer des paramètres dans le header à ce niveau.

Merci d'avance,

4 pts
Olivier Jaquemet · le 04/10/19 à 09:27

Bonjour Thomas,

La classe HttpClientUtils fourni des méthodes de très haut niveau pour les cas d'usages les plus standard de requetage et de récupération de données. Dès que des headers HTTP ou des comportements plus spécifique doivent être codés, alors il faut plonger dans le code.

Exemple

    CloseableHttpClient client = HttpClientUtils.newHttpClient(timeout);
    try {
      HttpGet method = new HttpGet(url);

      // header spécifique
      method.setHeader("Accept", "application/json");

      HttpResponse response = client.execute(method);

      // + gestion d'erreur etc ec


    } finally {
        IOUtil.closeQuietly(client);
    }
#3

Une méthode setAccept pourrait être la bienvenue et l'ajout d'un paramètre au niveau du constructeur :-) un peu comme cela a été fait avec le userAgent. Ca éviterait de se plonger un peu plus dans le code dès que nous souhaitons utiliser l'Open API avec le Json

Thomas LEGAT · le 04/10/19 à 11:04
#4

Alors en fait ... je comprends ton besoin, mais désolé, ça sera non 😪
Il y a déjà trop de méthodes dans cette classe utilitaire, ça commence à devenir le bazar.
Et ajouter des paramètres aux constructeurs, c'est les rendre plus complexe, ou ajouter encore et encore des signatures de méthodes.

Ce qui pourrait être intéressant si on souhaitait proposer quelque chose de plus riche permettant de personnaliser plein d'aspect, ça serait de partir sur un Builder pattern, ainsi là on pourrait éviter ces écueils, tout en rendant l'API évolutive. 
Cependant, on a pas encore assez de cas d'usage qui justifie de le faire et surtout malheureusement pas assez de temps à consacrer pour ça. Cependant, je note que si on devait avoir des modifications à faire sur cette classe -> évol en builder pattern avec prise en charge des personnalisation de ce type.

Merci de ta compréhension !

Olivier Jaquemet · le 04/10/19 à 11:11
#5

Pas de soucis, j'aurai tenté 😀

Thomas LEGAT · le 04/10/19 à 11:13
0 pt