gistfile1.json

{
	id: "4d49ca82",
	model: {
		href: "/foundation/v2/modelTypes/Product/models/140"
	}
	attribute: [
		{
			href: "/foundation/v2/attributes/title",
			value: [
				"Find the rabbit"
			]
		},
		{
			href: "/foundation/v2/attributes/images",
			value: [
				{
					href: "/business/v2/media/images/b28551d4"
				},
				{
					href: "/business/v2/media/images/dsfg879"
				}
			]
		},
		{
			href: "/foundation/v2/attributes/relatives",
			value: [
				{
					href: "/business/v2/families/b28551d4",
					model: {
						href: "/foundation/v2/modelTypes/Product/models/140"
					},
					attribute: [
						{
							href: "/foundation/v2/attributes/title",
							value: [
								"This is the voice"
							]
						}
					]
				},
				{
					href: "/business/v2/families/b2dfsg1d4",
					model: {
						href: "/foundation/v2/modelTypes/Product/models/142"
					},
					attribute: [
						{
							href: "/foundation/v2/attributes/title",
							value: [
								"Allez les bleus!"
							]
						}
					]
				}
			]
		}
	]
}

Humm sur cet exemple précis, non.
Values est de toute façon toujours un tableau, qui contient :

• soit un type simple ou tableau de types simples, comme les titres ; en Java, on aurait une List par exemple.
• soit un tableau de ressources liées, qui sont des objets complexes (~List, List). Dans ce cas, cela a du sens de les représenter sous forme de maps.

Si tu connais la structure de ta ressource (ex: elle possède N attributs simples nommés x,y,z, et des relations vers d'autres entités A,B,C), ce n'est pas très difficile à parser. Par contre, si tu découvres la structure quand tu la parses, effectivement, tu es obligé de vérifier dynamiquement le type de la valeur, et je t'accorde que c'est pénible.

@clakech T'es certain qu'il faut mettre les collections aux pluriel ?

La structure de la ressource n'est pas connue à l'avance... C'est en la parcourant qu'on découvre le type de chaque values

C'est vrai qu'il aurait mieux valu séparer les valeurs propres de l'entité, de ses relations.
Ainsi, pour les attributs propres, on saurait qu'il faut récucpérer un type simple, ou un tableau de types simples ; et pour les relations, on saurait qu'il faut récupérer une map.

{
    "id": "4d49ca82",
    "attributes": [
        {
            "name": "title",
            "values": ["Find the rabbit"]
        }
    ],
    "relations": [
        {
            "name": "images",
            "values": [
                {
                    "href": "/images/b28551d4",
                    "caption": "Hello"
                },
                {
                    "href": "/images/dsfg879",
                    "caption": "World"
                }
            ]
        },
        {
            "name": "relatives",
            "values": [
                {
                    "href": "/relatives/b28551d4",
                    "name": "Olga Rismov",
                    "age": 23
                },
                {
                    "href": "/relatives/f8984f",
                    "name": "Igor N.",
                    "age": 46
                }
            ]
        }
    ]
}

La question ne serait-elle pas : "La consistance dans la représentation des attributs rendrait-elle l'api plus lisible et plus pratique à utiliser ?"
Si la réponse est oui, alors il y a des améliorations à faire...
Mais si pour l'usage donné cette représentation était la plus pratique, alors le choix était le bon! Pragmatisme 👍 ;-)

Bref, si tu ne la trouves pas pratique, c'est qu'elle ne l'est pas.

Alexandre Bertails était passé au Bordeaux JUG nous expliquer JSON-LD, une sorte de XML Schema adapté à JSON. Ca permet de définir la structure et le type des attributs de chaque entité, au sein d'un contexte particulier. Au moins avec ça, on sait ce qu'on parse.

http://json-ld.org/