Accès WS REST "bas niveau"

Bonjour,
Je tente d’accéder aux webservices me permettant de lister modifier et supprimer mes objets depuis des appels en REST en v 4.0.

Mon authentification semble bien se passer (plus d’erreur 401), mais l’URL:
http://demo.XXXXX.fr/demo/api/rest/

Me renvoie une erreur 404. J’ai bien un utilisateur avec les droits sur l’objet et autorisé sur les “webservices” seulement.

Les appels vers http://demo.XXXXX.fr/demo/api/json/obj?object= fonctionnent bien en revanche.
Pourriez-vous m’éclairer sur ce problème ?

Merci d’avance,
Guillaume.

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:

  1. Si on est dans la UI générique Simplicité il n’y a aucune raison de taper sur les services de “bas niveau”
  2. 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, …)

Sinon pour faire simple le principe pour l’appel des services REST de bas niveau est:

  1. Obtenir un token sur /api/login avec un user+password:
  2. Utiliser ce token pour toutes les requêtes suivantes en /api/rest/... (tant que le token est valide)
    Données d’application:

    Données d’un objet métier:

    Etc.

C’est expliqué en détail dans les docs suivants:

Authentication: Simplicité® documentation/02-integration/services-auth
Services REST: Simplicité® documentation/02-integration/rest-services

Mais comme dit dans au début du doc sur les services REST si vous êtes dans les cas cités dans ma réponse précédente il ne faut surout pas réinventer la poudre mais plutôt utiliser les libs “wrappers” : standard Ajax/UI (Simplicité® documentation/03-apis/ajax-api) ou Node+Browser (Simplicité® documentation/03-apis/nodejs-api)

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.

Voici ce que j’obtiens:

Ca devrait pourtant marcher… Je vois 2 différences entre votre test et le mien:

  1. je suis en déploiement racine / là où vous êtes en /demo
  2. je vois 2 headers HTTP dans vos appels là où je n’en ai qu’un, quel est le 2ème header que vous passez ?

Pouvez vous faire un test sur /demo/api/rest/DemoClient/1 et sur /demo/api/rest/DemoProduct?inline_images=true ?

J’obtiens:

/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 ?

Merci !

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> .

Je vous tiens au courant.

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

Parfait, merci beaucoup !