Reprise du message précédent :
kad> http://www.leparisien.fr/diaporama [...] ar:www:une

Apres deux semaines pour avoir un JDK, le mec se pointe a l'heure de boufer, et est en plus incapable de faire une installe correctement ....
 
ah, il installe, il ne configure rien ...

putain, et ca fabrique des équipements de securité pour avion

*bip* *bip* *bip* *bip* *bip* mon estomac est en train de décrocher ....

Ouais mais ils le font pas en java

 
I have a bad news for you .....

je ne prends plus l'avion

VAMOS A LA PLAYA

ça prouve bien que les algues vertes sont pas dangereuses

 
Je te rappelle quand même que ce sont des chinois et que la Chine est le deuxième endroit le plus toxique de la terre après la mère de stiffler

C'est surtout stupide. ça ne sert à rien de tout documenter, il faut documenter ce qui est critique (les processus de build et de deloyment), ce qui est incompréhensible autrement (le super algo de la mort pour faire un clone virtuel de George) et ce qui est visible par l'exterieur (la GUI, l'API pour les plugins).  
Après, la doc est une tache comme une autre, c'est chiant mais si la chose à documenter est précise et que le périmètre est limité, c'est moins un clavaire pour la personne qui écrit la doc

 
Putain mais ça devient n'importe quoi cette histoire ! Je viens de passer devant chez ubisoft, il doit y avoir 30 personnes et DEUX équipes de télévisions dans la rue en train de mater les fenêtres. Tout ça pour des bouts de papiers collés aux carreaux

<ul>
     <li><label for="id_whats_up_0"><input type="radio" name="whats_up" value="1" id="id_whats_up_0"> Foo</label></li>
     <li><label for="id_whats_up_1"><input type="radio" name="whats_up" value="2" id="id_whats_up_1"> Bar</label></li>
     <li><label for="id_whats_up_2"><input type="radio" name="whats_up" value="3" id="id_whats_up_2"> Baz</label></li>
</ul>

 
Putain Django, c'est quoi l'intêret de foutre l'input là

Vous avez une bonne ressource sur l'intarwebz, compréhensible par le manager de base, qui explique pourquoi il vaut mieux choisir REST que SOAP (et d'ailleurs, faut-il être si tranché) ?
 
L'idée générale est que SOAP = bloat (le dissaïdor s'en cogne) et REST = simple (ça fait peur au dissaïdor), mais nulle part je trouve réellement un set d'arguments valides plutôt qu'un débat stérile.

Ca vient d'ici ce lien ?  
http://www.thedominoproject.com/20 [...] tings.html
 
"Read this before our next meeting" a 681 pages, je suis pas sur que ça va se lire beaucoup.
 
Bon, comment on transforme un truc kindle en pdf ?

tu le renommes en .mobi et après, je sais pas

 
Ca m'intéresse aussi de savoir.

 
J'ai essayé avec Calibre ce matin, il grogne sur les DRM, donc supprimer la protection avant.
 

 
J'ajoute qu'en défaveur de REST, il y a le manque de (connaissance sur) les librairies clientes dans les différents langages. En Java, il y a Jersey par exemple, mais je pense que le nombre de développeur capable de générer un client via un WSDL est bien supérieur à celui des devs qui connaissent ce type d'API.
 

En même temps si t'arrives à faire un truc suffisament compliqué pour que ça nécessite de connaitre plus que la hierachie des URI et quelques verbes HTTP : you are doing it wrong.

Même à grande echelle y'a pas besoin de tant de connaissances que ça comparé à SOAP. L'idée principale de REST c'est quand même que ton API soit expressive, si ton code métier fait entrave au concept je vois pas l'intérêt.

en quoi y'a t'il besoin d'une librairie cliente pour accéder à un webservice REST ? un simple HttpUrlConnection (en Java) suffit non ? avec éventuellement un parser Json ou XML derrière pour récupérer les infos ?

oh bah ça c'est original

Non seulement tu arrive à dormir les yeux ouverts mais en plus tu arrive à donner le change quand le boss te surprend

Donc ça te laisse Macon ou Macon...

http://www.numerama.com/magazine/1 [...] yrock.html
 
C'est moi ou Orange se spécialise dans l'achat de boîtes à caca ?

non, c'est ça, REST est plus simple d'accès, le protocole plus simple etc.
 
Mais REST pose un énorme problème avec une définition complètement intégriste et pas simple à saisir, donc mon idée c'est d'éviter d'appeler ton truc REST, tu fais une interface qui y ressemble, (avec du POST, du GET, des accept: etc.)  t'appelle ça "WEB API" et en voiture Gertrude. Si tu tombes sur un Masklinn : "fuck, j'ai rien promis". Tous les autres vont reconnaitre du REST et c'est bon.
 
Sachant que les API réellement REST-JSON sont incompatibles avec la plupart des navigateurs (qui n'acceptent pas le type JSON).

c'est une compétence apprise et devellopé pendant ma scolarité  

macon / chalon / bourg en bresse( commence être limite) / villefranche
 
Je ne suis pas pressé et les conditions matérielles sont pas mal ici.

Oui enfin fondamentalement pour faire du REST/HTTP t'as juste besoin d'un client HTTP (ou d'un serveur si t'es le fournisseur)

Ratal, une API REST la seule URL dont t'as besoin c'est l'entry point (la racine), par contre tu dois connaître les content-types

http://www.lefigaro.fr/flash-actu/ [...] ux-jmj.php
'va y avoir de la catho à Madrid !
(et mon ex. )

C'est bien de wrapper ça dans un truc un peu moins moche, donc ça rejoins ce que je dis, t'as pas besoin de 1000 lignes de code (enfin en Java je sais pas) pour faire un client REST.

au lieu de l'orthographe ...  

ça commence ...

 
On est d'accord, maintenant je préfère la seconde à la première version de cette réponse, aussi bien pour moi que pour les autres. La lib client c'est du confort, et ça permet aussi de vendre REST plus facilement qu'en demandant aux clients du webservice de gérer les appels HTTP à la mano. Accéssoirement, et même si c'est très con, la lib assoit la techno vis-à-vis des dissaïdors.
 

 
Ma crainte sur le REST vs SOAP est justement le manque de reconnaissance du premier en entreprise. Si je shoot l'appellation (déjà pas bien reconnue) REST pour ne laisser que des appels HTTP nus, j'ai peur de :
- revenir à ma question de base, à savoir comment vendre HTTP / WEB API vs SOAP ;
- ne plus avoir les arguments d'autorité style thèse / références pour REST.
 

Et le fournisseur de service peut offrir une lib avec une API un peu plus simple à utiliser que devoir monter ton truc à la main à base, genre pour les 2-3 langages principalement supportés.

C'est aussi un avantage, tu peux montrer ça à un guru du REST, le faire gerber et t'auras quand même un truc compréhensible par le premier FlorentG venu

C'est ce que je dis, t'as besoin de savoir comment ton set de données s'articule à partir du point d'entrée (enfin ça c'est la définition intégriste). Les content-types dans le monde réel y'en à pas 20 non plus

Villefranche et Chalon n'étant pas des prefecture, j'imagine que c'est relativement limité pour trouver un boulot de développeur dans la fonction publique, non ?

Bah non, tu dis que ça doit connaître la hiérarchie d'URL. HATEOAS dude

Bah si, le content type à connaître c'est pas le MIME standard, avoir application/xml ou application/json tu peux rien en faire, tu dois savoir comment le document est structuré et où sont les données à extraire. C'est ça le content type. Après tu peux (c'est l'idéal) définir le MIME qui va bien pour (en spécification d'un MIME existant par exemple), mais c'est pas la partie la plus importante.

Donc si ton API ne deale pas dans des formats spécifiques standard (genre du KML ou du iCalendar) tu vas bien devoir définir un content type pour ton service.

On est parti sur du SOAP ici pour exactement cette raison, enfin, on a présumé que ça ferait flipper les mecs avec qui ont discutent qui font tout sous windows. L'API mise à dispo est pas simple à manipuler si t'as pas un client qui va bien, mais au moins tu leur files une WSDL et tu sais si tu parles à quelqu'un qui à un minimum de compétence sur le sujet ou pas, une fois pris en main ça serait dommage qu'on recoive des questions sur le type des paramètres ou autre connerie - et ça n'est pas encore arrivé

 
pas tant que ça
les communauté de communes ont plus de moyens que les conseil régionaux / grosses villes sur de nouveaux projets.  Mais les postes en dev sont assez rares dans la fonction publique ( rarissime à l'echellon ingénieur : un ingé est en col blanc et ne se salit pas les mains avec du code )

Bin voilà. Et autant j'ai des arguments techniques à exposer en faveur de REST, autant avec la bardée d'outil qu'il y a autour et la génération automatique, SOAP marque des points.

Le protocole REST est simple, mais la mise en place de SOAP est moins risquée d'une façon pratique. C'est pour ça que je galère sur l'argumentation

Pour la partie serveur, si tu fais du REST comme un homme, t'es censé savoir comment organiser tes URLs pour qu'elles suivent une logique au sens HTTP. En fait, ta lib coté serveur doit être capable de faire ça à partir d'un jeu de données.
 
J'ai pas parlé de client.