Gestion d'un nouveau type d'attribut primitif "JSON"

[bmo (Bruno Montagnac)]

Version

6.2

Description

Nous sommes amenés dans certains cas à gérer un sous-ensemble d’information structurée au format JSON à la maille object field. Le type primitif utilisé dans ce contexte est “Texte long” et les opérations réalisées sont supportées par des instances de JSONObject sérialisées/désérialisées lors des interactions avec le modèle logique.

Lorsque l’attribut d’objet est exposé via une API, le contenu de l’object field est servi en tant que String

{
  ...,
  "thereWeHaveJson": "{\"key\": \"value\"}",
  ...
}

Serait-il envisageable que l’object field soit de type primitif JSON pour

1. pouvoir directement utiliser l’instance de classe JSONObject lors des get|setValue
2. pouvoir directement disposer de la structure JSON dans le body servi par l’API

{
  ...,
  "thereWeHaveJson": {
    "key": "value"
  },
  ...

}

Par extension de cette logique, est-il envisageable que les autres types primitifs soient servis tels que dans le body json ? (entiers et booléen en particulier)

[david (David AZOULAY)]

Bonjour

Normalement il suffit mettre le rendering JSON sur l’attribut de type texte long pour que celui-ci soit servi en tant que “raw” JSON au niveau des APIs standards:

avec:

[bmo (Bruno Montagnac)]

Bonjour David, je me jette là-dessus

Merci beaucoup pour ta réponse rapide.

[david (David AZOULAY)]

A vérifier si c’est géré dans les APIs “mapped”, j’ai un doute sur ce point.

PS:

S’agissant de JSON “contraint” il est classique d’implémenter une validation vs un schema JSON dans le postValidate (le schema JSON en question pouvant, par exemple, être stocké dans une ressource de type JSON) :

String schema = HTMLTool.getResourceJSONContent(getGrant(), "MY_JSON_SCHEMA");
List<String> errs = new JSONSchemaTool(schema).validateJSON(getFieldValue("myJSONField"));

Cela garantira que la réponse JSON de l’appel API sera structurellement correcte

[bmo (Bruno Montagnac)]

@david

A vérifier si c’est géré dans les APIs “mapped”, j’ai un doute sur ce point.

J’ai vérifié et a priori, non, ce n’est pas géré… :’(

[david (David AZOULAY)]

OK je regarde ça au niveau des APIs mappées, car idéalement ça ne devrait pas se comporter différemment

[bmo (Bruno Montagnac)]

Merci David

Je confirme que j’ai bien la même différence de comportement entre une 5.3 et une 6.2 “à jour”:

• JSON bien rendu via l’API interne `/api/rest/RenaultModule/xx`
• JSON sérialisé en String via l’API mappée `/api/QodHubV2/data-base-specifications/xx`

[david (David AZOULAY)]

Je reproduis effectivement aussi sur la v7:
API standard:

vs API mappée:

Configurée comme suit:

Settings =

{
  "objects": [{
    "name": "test1",
    "fields": [
      {
        "field": "appTst1Code",
        "name": "code",
        "desc": "Code"
      },
      {
        "field": "appTst1Lable",
        "name": "label",
        "desc": "Label"
      },
      {
        "field": "appTst1Description",
        "name": "description",
        "desc": "Description"
      }
    ],
    "object": "AppTest1",
    "desc": "Test 1"
  }],
  "name": "Mapped API for test1"
}

A suivre…

[david (David AZOULAY)]

C’est corrigé:

Ce sera livré en v7, en v6 (6.2.22 & 6.3.1) et en v5 (5.3.83)

Attention vérifier que cette correction ne provoquera pas de régressions du coté des clients de ces APIs qui auraient contourné le pb en faisant un parsing JSON de la valeur JSON renvoyée sous forme de chaine de caractères (la correction en question ne concerne bien que les fields de type texte long avec rendering JSON)