Hello!
 
j'ai besoin d'un réponse urgente sur un point.  
 
attention, je ne suis pas développeur..
 
je dispose d'une appli avec une API de type web service http REST
 
une autre appli en JAVA v1.3 (une antiquité).
 
Je dois valider la faisabilité de modifier une class java existante utilisée par cette appli pour faire appel à cette API web service?
Les développeurs que j'ai sous la main sont plus spécialisés PHP ou .net que java... ils ont donc du mal à m'aider
 
est-ce que c'est possible? simple à développer? est-ce que le fait d'avoir une version moyen-ageuse de java imposée est bloquant?
 
merci de votre aide.... j'ai besoin d'une réponse dans l'heure si possible.

Non pas possible.  
 
Java 1.3 ... donc avant avant Java 2, donc avant J2EE.
Une application du siècle dernier ?
Tu vas avoir besoin d'utiliser des API qui ne vont pas être compatible Java 1.3. Et qui ont des dépendances non compatibles 1.3
Donc développer beaucoup de choses à la main. Tellement que ça enlève tout intérêt.
 
 

 
Java 2, c'était Java 1.2 (faut pas chercher la logique), et il y a bien eu un j2ee 1.3. Mais c'est vrai que c'est vieux et qu'il risque d'y avoir beaucoup de choses qui ne fonctionneront pas

du genre quoi? besoin de développer "à la main" l'ouverture du socket TCP dans lequel envoyer la requête HTTP? c'est un gros boulot?

L’application date effectivement du siècle dernier et il n'est pas envisageable d'y toucher.... c'est bien là le problème.

L'API de référence en REST est jersey.
Donc tu vas appeler le service REST en utilisant l'API Jersey.
Et tu vas voir que Jersey n'est pas compatible 1.3.
Ou une des dépendances ne le sera pas.
https://jersey.java.net/documentati [...] ncies.html
All Jersey components are compiled with Java SE 6 target.
 
Un petit exemple des façons de faire avec ou sans Jersey.
http://harryjoy.com/2012/09/08/sim [...] t-in-java/
 
Comme dans l'exemple, tonc tu pourras te rabattre sur des biblis intermédiaires comme le Apache HttpClient.
Il y a aussi des dépendances...
 
La dernière solution est d'appeler le service REST en get http (java.net) et déparser le flux xml "à la main".

merci de ces précisions

donc si je comprends bien, y'a du boulot, mais c'est faisable....

ça se compte en heures, en jours, en dizaines de jours ou en centaines de jours?

Ca dépend de la complexité du web service dont il faut lire la réponse.
Les objets xml renvoyés sont ils complexes ? Des attributs listes ? Des attributs optionnels ?

extrait de la doc de mon API (attention, pour moi, c'est presque du chinois):
Exemple d'appel en mode connecté (TCP)
<?xml version="1.0" encoding="utf-8"?>
<kiamoAPI type="AGENT">
 <request command="agentCallDial" requestID="174a1x5r8">
   <params>
     <agentID>42</agentID>
     <calledNumber>0556881895</calledNumber>
   </params>
  </request>
</kiamoAPI>

Exemple d'appel en mode déconnecté (REST)
<request command="agentCallDial">
 <params>
  <called_number>0556881895</called_number>
 </params>
</request>

Exemples de réponse en cas d’erreur
Voici un exemple de message d’erreur :
<?xml version="1.0" encoding="utf-8"?>
<kiamoEvent type="AGENT"> <event name="agentErrorMessage"> <agentID>2</agentID> <errorMessage>you_dont_have_call_license</errorMessage>
</event>
</kiamoEvent>

Voici un message d’erreur dans le cas où le téléphone de la personne appelée sonne occupée :
<?xml version="1.0" encoding="utf-8"?>
<kiamoEvent type="AGENT">
 <event name="agentCallResult">
  <agentID><![CDATA[537]]></agentID>
  <result><![CDATA[cust_busy]]></result>
 </event>
</kiamoEvent>

je soupçonne (mais ai-je bien compris?), que le paramètre agentID n'est pas demandé en mode déconnecté car j'imagine que c'est l'ID déjà indiqué dans l'en-tête qu'il faut générer:
 
"POST HTTP://kiamo/api/agent/{id}"

cette fonction à à priori la seule dont j'ai besoin...

On est sur un forum pour causer de résolution de problèmes java, les corrections de devoir exclues.
Ce que tu demandes également.  
Embauches un indépendant ou trouves un spécialiste chez toi ...  
Par ailleurs, je pense que la personne qui évaluera devra développer  
ou alors connaitre les développeurs.
 
PS : si il faut gérer les messages d'erreurs + les réponses nominales, le tout sans API REST, il y a du travail