Où se trouve le problème en utilisant http get+xml comme web service?

Salut à tous

Dans l'utilisation des web services, le standard SOAP+WSDL+UDDI a été utilisé longtemps, mais je le trouvais franchement très compliqué pour les scénérios les plus courants. Je crois que je n'ai été le seul, car actuellement beaucoup adopte REST pour réaliser les web services. Mais franchement je le trouve toujours bien compliqué.
En fait je ne comprend toujours pas pourquoi utiliser plusieurs VERB http (GET, PUT, DELETE, POST) alors que avec le GET on peut tout faire et en plus en utilisant un simple navigateur, on peut consommer directement tout Web Service en mode "interactif", et en developpant, on n'a pas besoin d'utiliser d'API supplémentaire.
Par exemple, si je veux créer un nouveau client, je peux utiliser simplement l'url:
http://monserveur/create-customer?name=name1&age=15. qui renvoie document XML contenant l'id du client créer. Franchement je trouve cela très simple, très naturel d'ailleurs.
Pourquoi les standard Web services ne préconisse par tout simplement un simple http get pour implémenter les web services?

Citation:

---

Envoyé par kisitomomotene

Pourquoi les standard Web services ne préconisse par tout simplement un simple http get pour implémenter les web services?

---

Je dirais, parce que tu es assez grand pour y penser tout seul. Pour ceux pour qui cette approche a trop de limites, on en a inventé d'autres, dont REST.

Pour commencer, sache que REST est plus une manière de voir les choses, qu'un standard précisément défini. Si tu n'aimes pas PUT et DELETE, ne te sers que de GET et de POST, et puis c'est tout !
Tu dis que "on peut tout faire avec GET," mais c'est faux. Envoyer une donnée assez grosse ne peut pas raisonnablement se faire en GET. Un POST (ou un PUT pour les puristes) est plus adapté, et même parfois la seule solution.

Il y a d'autres choses. Quand on veut envoyer des données, même pas très grosses, on peut chercher à le faire en XML, tout simplement parce qu'en XML, on sait déjà une bonne partie de ce qu'on peut envoyer et ne peut pas envoyer. Cerise sur le gâteau, on peut fournir un schéma qui vérifie la validité et qui auto-génère les classes sérialisables. Tu vas me dire que c'est possible avec du pur GET aussi. Moi je te parle là d'un truc qui ne prend guère plus d'un quart d'heure, et que les utilisateurs compétents comprendront par eux-même, sans ambiguïté. Dans tous les langages. Pas de coût pour gérer tout ça.

Également, REST n'est pas tellement une question de simplifier la programmation, mais plutôt d'avoir une plate-forme cohérente et sémantiquement expressive. Une URL est en fait une URI, une ressource, un objet disponible ou à mettre à disposition. Ce n'est pas une simple fonction distante à appeler.
Voir les choses de cette manière permet d'exposer comment on a vu les forces en présence. La documentation se fait simplement, la plupart des choses vont de soi. Bref c'est plus une manière de séparer ce qui est une ressource de ce qui est un paramètre et de ce qui est un traitement, pour inviter les gens à mieux comprendre et à venir se servir.
On peut faire autrement, mais bien fait ça marche pas mal.

* Bon, ceci étant dit, des APIs REST bien foutues, j'en ai pas vu des masses. Il y a le Facebook Graph, et quelques APIs Google, mais sorti de ça...