Est-il possible de créer un client REST avec Flex ?

Question

Je commence un projet utilisant une architecture Restful implémentée en Java (utilisant la nouvelle norme JAX-RS).

Nous envisageons de développer l'interface graphique avec une application Flex. J'ai déjà trouvé quelques problèmes avec cette implémentation en utilisant le composant HTTPService (les codes d'erreur de réponse, l'accès aux en-têtes...).

L'un d'entre vous a-t-il de l'expérience dans un projet similaire ? Est-il réalisable ?

Answer 1

Le problème est qu'un grand nombre de discussions sur le web autour de cette question datent d'un an ou plus. Je travaille actuellement sur cette même recherche, et voici ce que j'ai appris aujourd'hui.

Ce site Article d'IBM Developer Works d'août 2008 de Jorge Rasillo et Mike Burr montre comment réaliser une application Flex front-end / RESTful back-end (exemples en PHP et Groovy). Bel article. Bref, voici ce qu'il faut retenir :

• Leur code PHP/Groovy utilise et attend PUT et DELETE.
• Mais le code Flex doit utiliser POST, mais définir l'en-tête HTTP X-Method-Override sur DELETE (vous pouvez faire de même pour PUT, je présume).

• Notez que c'est pas la méthode Proxy discutée ci-dessus.

  // Flex doesn't know how to generate an HTTP DELETE. // Fortunately, sMash/Zero will interpret an HTTP POST with // an X-Method-Override: DELETE header as a DELETE. deleteTodoHS.headers['X-Method-Override'] = 'DELETE';

Que se passe-t-il ici ? Le serveur web IBM intercepte et interprète le "POST with DELETE" comme un DELETE.

Alors, j'ai creusé davantage et j'ai trouvé ceci post et discussion avec Don Box (l'un des premiers responsables de SOAP). Apparemment, il s'agit d'un comportement assez standard puisque certains navigateurs, etc. ne supportent pas PUT et DELETE, et c'est une solution de contournement qui existe depuis un certain temps. Voici un extrait, mais il y a beaucoup plus de discussion.

"Si je construisais un client GData, je me demande honnêtement pourquoi je m'embêterais à utiliser les méthodes DELETE et PUT, étant donné que X-HTTP-Method-Override va fonctionner dans plus de cas/déploiements."

Si votre site Web prend en charge l'en-tête X-Method-Override, vous pouvez utiliser cette approche. Les commentaires de Don Box me font penser qu'il est assez bien supporté, mais je ne l'ai pas encore confirmé.

Un autre problème se pose quant à la possibilité de lire les en-têtes de la réponse HTTP. Encore une fois, de un billet de blog en 2007 par Nathan de Vries nous voyons cette discussion. Il a fait suivre cet article de blog et cette discussion de son propre commentaire :

"Le seul changement sur le front du web est que les nouvelles versions de Flash Player (certainement celles fournies avec la version bêta de Flex 3) prennent désormais en charge la propriété responseHeaders sur les instances de HTTPStatusEvent."

J'espère que cela signifie que ce n'est plus un problème maintenant.

Answer 2

Comme beaucoup l'ont souligné HTTPService est un peu simpliste et ne fait pas tout ce que vous voulez faire. Cependant, HTTPService est juste du sucre sur le dessus de la flash.net.* des classes comme URLLoader , URLRequest et URLRequestHeader . En les utilisant, vous pouvez assembler la plupart des requêtes HTTP.

En ce qui concerne la prise en charge des méthodes autres que GET et POST, le problème réside principalement dans le fait que certains navigateurs (par exemple Safari) ne les prennent pas en charge et que Flash Player s'appuie sur le navigateur pour toute sa mise en réseau.

Answer 3

La capacité de Flex à agir comme un client RESTful pur présente des lacunes évidentes.

Les commentaires ci-dessous proviennent de ce blog :

Le problème est que la classe HTTPService a plusieurs limitations majeures :

1. Seules les méthodes GET et POST sont prises en charge d'emblée (à moins que vous ne utilisez FDS et définissez l'attribut useProxy à true)
2. Impossible de définir les en-têtes de la demande et il n'y a pas d'accès aux en-têtes de la réponse. de réponse. Par conséquent, je ne suis pas en mesure accéder au corps de la réponse en cas d'erreur d'une erreur.
3. Si HTTPService obtient un code de statut autre que 200, il considère une erreur. (événement 201, ouch !!). Le site FaultEvent ne fournit pas d'information sur le code d'état ou sur la réponse corps. Le client Flex n'aura aucune idée de ce qui a mal tourné.

Matt Raible a également donné un belle présentation sur REST avec Rails, Grails, GWT et Flex qui ont quelques bonnes références liées à elle.

Le fait que ce soit faisable ou non dépend vraiment de ce que vous êtes prêt à contourner en utilisant la procuration, etc.

Answer 4

J'ai travaillé sur un remplacement open source pour le composant HTTPService qui supporte entièrement REST. Si vous êtes intéressé, vous pouvez trouver la version beta (code source et/ou bibliothèque d'exécution partagée Flex compilée) et les instructions ici :

http://code.google.com/p/resthttpservice/

Answer 5

La réponse courte est oui, vous pouvez faire du RESTful avec Flex. Il suffit de contourner les limites du lecteur Flash (plus performant avec les dernières versions) et les limites de la pile HTTP du navigateur contenant.

Cela fait plus d'un an que nous développons des clients RESTful en Flex, après avoir résolu le problème de l'en-tête de requête HTTP de base et de l'absence de PUT et DELETE via l'approche ?_method= de Rail. C'est peut-être inélégant, mais cela permet de faire le travail.

J'ai noté certaines des douleurs d'en-tête dans un ancien billet de blog à l'adresse suivante http://verveguy.blogspot.com/2008/07/truth-about-flex-httpservice.html