Ajouter un paramètre d'expension de la resource

[yohanboniface]

Les resources dans une collection sont par défaut servies en mode compact: i.e. seules les propriétés de la resource plus les identifiants des relations de premier niveau.

Par exemple, en très simplifié, pour un HouseNumber d'une collection:

{
    "number": "12",
    "parent": "ban-group-0446e6ffd613476eb7e0abccbe84fa10",
    …
}

Pour optimiser les appels et faciliter la vie des utilisateurs, il faudrait pouvoir avoir des représentations détaillées des relations.

Ce qui se fait souvent et me semble répondre au besoin, c'est d'avoir un paramètre expand, qui prend comme valeur une liste de champs qu'on veut étendre, par exemple

/housenumber/?expand=parent,parent.municipality

Ce qui donnerait quelque chose comme:

{
    "number": "12",
    "parent": {
        "name": "rue des Lilas",
        "municipality": {
            "name": "Palavas-les-Flots",
            …
        },
        …
    },
    …
}

cc @davidbgk @vinyll si vous avez des recommandations sur le sujet.

Lié à #176

[davidbgk]

Il s'agit pour moi du principal enjeu autour de GraphQL (vidéo), @noirbizarre a implémenté ça dans notre lib Flask via les headers, ce que je trouve plus élégant.

Par contre, je recommande de rester conforme à la syntaxe qui sera peut-être standardisée un jour si Facebook y voit un intérêt 😃

[yohanboniface]

Il s'agit pour moi du principal enjeu autour de GraphQ

Merci, je creuse par là :)

via les headers, ce que je trouve plus élégant.

humm, mais ça veut dire qu'une même URL peut avoir deux représentations différentes? Ça pose de pas de problème de cache, proxy… ?

[yohanboniface]

Très intéressant GraphQL en effet pour ce pattern! Mais j'ai l'impression que REST et GraphQL sont deux paradigmes qui sont pas tout à fait réconciliables: en gros d'un côté des endpoints /resource/id, de l'autre un endpoint unique avec une syntaxe dédiée pour requêter. Et j'ai l'impression que vouloir les faire cohabiter enfoncerait un coin dans le KISS, fondation mère de la maintenabilité d'un code as you know :) Sans compter Swagger derrière tout ça, qui rigidifie les concepts de REST et me semble pas super GraphQL ready. Bref, un peu overkill pour notre cas?

[vinyll]

Est-ce que l'approche de @noirbizarre est pas envisageable (x-fields) avec sa proposition d'écriture {number, parent{name, municipality{name}}} dans les params en get et en headers dans le reste ?

[yohanboniface]

Voir #198

[yohanboniface]

Fixed by #198