Avant d’investiguer en détail votre problème pourriez vous me préciser dans quel contexte et me dire quel(s) languages vous utilisez pour vos appels ?
En effet:
Si on est dans la UI générique Simplicité il n’y a aucune raison de taper sur les services de “bas niveau”
Si on est à l’exterieur de Simplicité, si on parle de Javascript navigateur ou de node.js je vous suggère d’utiliser la lib suivante: https://github.com/simplicitesoftware/nodejs-api (il y a sur le même compte GitHub des repo d’exemple dans diverses technos : Angular, React/React native, Vue.js, …)
Bonjour David,
Merci de votre réponse. Notre besoin est d’intégrer des données provenant d’une source externe par l’intermédiaire de notre bus de services. Nous souhaitons les intégrer par l’API afin d’éviter les connexions directes à la base.
/demo/api/rest/DemoClient/1 -> Erreur 400 (malformed uri)
/demo/api/rest/DemoProduct?inline_images=true -> idem : Erreur 404 (Object not found or not granted)
Le 2ème header était une mauvaise manip d’un test précédent que j’ai supprimé, il ne me reste qu’un header de type “bearer”.
Le “malformed URI” me laisse penser que ce serait dû au “/demo”. Pensez-vous que cela puisse être le cas ?
Je vais faire des tests car vous êtes, à ma connaissance, les seuls à ne pas déployer vos instances Simplicité en racine, il y a donc peut être un bug dans le parsing d’URL quand on est en /<app> .
OK je reproduis bien les symptômes indiqués sur une instance en /app, il y a donc bien une régression dans ce cas je vous tiens au courant pour la correction
La régression sur le parsing d’URI dans le cas d’un context path non racine est corrigée, ça a été poussé sur la branche master et ça sera releasé en 4.0 P20 d’ici la fin de la semaine