Comment surcharger le nom d'un attribut d'une réponse dans une api

Support
1

Bonjour
j’expose une api contenant entre autres la ressource Structural Unit.
Mes guidelines sont les suivantes :

  • Le noms des ressources est en spinal case (ex: structural-units)
  • Le nom des attributs est en camel case (ex : monAttribut)

J’ai donc créé le mapping suivant

public class IT4ITServicesV1 extends com.simplicite.webapp.services.RESTMappedObjectsExternalObject {
	private static final long serialVersionUID = 1L;

	@Override
	protected void init(Parameters params) {
		setUseCache(false);
		setOpenAPISpec(JSONTool.OPENAPI_OAS2);
		setOpenAPIDesc(getDesc() + "\n\n> Business model version : **" + getGrant().getVersion() + "**");
		setOpenAPIBasePath("/it4it/v1");

		addObject("structural-units", "IT4ITStructuralUnit");
		addField("structural-units", "id", "row_id");
		addField("structural-units", "identifier", "it4itGenIdentifier");
		addField("structural-units", "name", "it4itGenName");
	}
}

Mon problème est que dans le swagger généré par Simplicité, j’obtiens pour la méthode GET, le retour suivant :

image
image763×439 13.8 KB

Simplicité retourne un objet contenant un tableau de ma ressource avec le nom de la ressource. Or comme le nom de la ressource est en spinal case, cela ne valide pas la guideline sur le nom des attributs.
D’où ma question : comment surcharger le nom de l’attribut contenu dans le retour ?

Merci d’avance
Amandine

[Platform]
Status=OK
Version=4.0.P24
BuiltOn=2020-02-05 10:36 (revision 4271ab3e8ebfa613335f5cb919c3f3d2077b7a28)
Encoding=UTF-8
EndpointIP=172.17.0.5
EndpointURL=http://1271acf15d72:8080
TimeZone=Europe/Paris
SystemDate=2020-02-11 17:21:53

2

Ce que produit le wrapper RESTMappedObjectsExternalObject est sensé être conformes à vos normes (puisqu’il a justement été développé pour l’être).

Si le point que vous remontez était un pb je pense qu’il aurait déjà été remonté. Je pense donc qu’on est plus dans un pb d’interprétation des normes…

@bmo peux tu regarder ce point ? Merci

3

Bonsoir David,
ce point a été revu avec nos experts API et architecture data.
Le problème initial relevait effectivement d’une incohérence des normes internes entre le formalisme de nommage des ressources dans les URI (spinal-case) et dans les BODY (lowerCamelCase).
Nous avons finalement tranché pour le formalisme lowerCamelCase pour l’ensemble des ressources et propriétés. la reprise de nos mappings est en cours.
Bruno