Est-il possible de créer un client REST avec Flex?
https://stackoverflow.com/questions/153420
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Je commence un projet utilisant une architecture reposante mise en œuvre en Java (utilisant le nouveau standard JAX-RS)
Nous prévoyons de développer l'interface graphique avec une application Flex. J'ai déjà constaté des problèmes avec cette implémentation à l'aide du composant HTTPService (codes d'erreur de réponse, accès aux en-têtes, etc.).
Chacun d'entre vous a de l'expérience dans un projet similaire. Est-ce faisable?
La solution
Le problème, c’est que la plupart des discussions en ligne sur ce sujet datent d’un an ou plus. Je travaille actuellement sur la même recherche, et c’est ce que j’ai appris aujourd’hui.
Ce article de IBM Developer Works d'août 2008 par Jorge Rasillo et Mike Burr montre comment créer une application back-end Flex front-end / RESTful (exemples en PHP et Groovy). Bel article. Quoi qu'il en soit, voici le plat à emporter:
- Leur code PHP / Groovy utilise et attend PUT et DELETE.
- Mais le code Flex doit utiliser POST, mais définit l'en-tête HTTP X-Method-Override sur DELETE (vous pouvez faire la même chose pour PUT I présume).
- Notez que ceci n'est pas la méthode proxy décrite 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 avec DELETE " comme DELETE.
J'ai donc approfondi et trouvé ce poste et discussion avec Don Box (l’un des gars originaux de SOAP). Apparemment, il s’agit là d’un comportement assez standard, car certains navigateurs, etc., ne prennent pas en charge les méthodes PUT et DELETE. Voici un extrait, mais il y a beaucoup plus de discussions.
& "; Si je construisais un client GData, honnêtement, je me demandais pourquoi je m'embarrasserais d'utiliser les méthodes DELETE et PUT, étant donné que X-HTTP-Method-Override fonctionnerait dans davantage de cas / déploiements. "
D'après ce que j'en déduis, si votre site Web prend en charge cet en-tête X-Method-Override, vous pouvez utiliser cette approche. Les commentaires de Don Box me font penser qu'il est assez bien soutenu, mais je ne l'ai pas encore confirmé.
Un autre problème concerne la possibilité de lire les en-têtes de réponse HTTP. Encore une fois, à partir de un billet de blog publié en 2007 par Nathan de Vries , nous voyons cela discuté. Il a ensuite suivi ce blog et la discussion avec son propre commentaire:
& "Le seul changement sur le Web est que les versions les plus récentes de Flash Player (certainement 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 qu'il ne s'agit pas d'un problème maintenant.
Autres conseils
Comme beaucoup l'ont déjà souligné, HTTPService est un peu simpliste et ne fait pas tout ce que vous voulez. Cependant, flash.net.* ne fait que s'ajouter aux URLLoader classes telles que URLRequest, URLRequestHeader et <=>. En les utilisant, vous pouvez assembler la plupart des requêtes HTTP.
En ce qui concerne la prise en charge de méthodes autres que GET et POST, le problème réside principalement dans le fait que certains navigateurs (Safari, par exemple) ne les prennent pas en charge, et que Flash Player s’appuie sur le navigateur pour tous ses réseaux.
La capacité de Flex à agir en tant que client RESTful pur présente des défauts évidents.
Les commentaires ci-dessous proviennent de cette blog :
Le problème est que la classe HTTPService a plusieurs limitations majeures:
- Seules les méthodes GET et POST sont prises en charge immédiatement (à moins que utiliser FDS et définir l'attribut useProxy sur vrai)
- Impossible de définir les en-têtes de requête et aucun accès à la réponse en-têtes. Donc je ne suis pas capable de accéder au corps de réponse dans le cas d'une erreur.
- Il HTTPService obtient un code d’état tout autre 200, il considère une erreur. (événement 201, aïe !!). le FaultEvent ne & # 8217; t ne fournit aucune information sur le code d'état toute réponse corps. Le client Flex n'aura pas idée de ce qui a mal tourné.
Matt Raible a également fourni un belle présentation sur REST avec Rails, Grails, GWT et Flex contenant de bonnes références.
Que cela soit réalisable ou non dépend vraiment de votre volonté de contourner le problème en utilisant une procuration, etc.
J'ai travaillé sur un remplacement open source du composant HTTPService qui prend entièrement en charge REST. Si vous êtes intéressé, vous pouvez trouver la version bêta (code source et / ou bibliothèque d'exécution partagée Flex compilée) et les instructions ici:
La réponse courte est oui, vous pouvez utiliser RESTful avec Flex. Il vous suffit de contourner les limites du lecteur Flash (optimisées avec les dernières versions) et les limites de la pile HTTP du navigateur qui les contient.
Nous travaillons au développement RESTful de clients dans Flex depuis plus d'un an après avoir résolu l'en-tête de base de la requête HTTP et l'absence de PUT et DELETE via la méthode rail-esque? _method =. Tacky peut-être, mais il fait le travail.
J'ai remarqué la douleur dans l'en-tête d'un ancien billet de blog intitulé http://verveguy.blogspot.com/2008/07/truth-about-flex-httpservice.html
La prise en charge de Flex pour REST est au mieux faible. J'ai passé beaucoup de temps à construire un prototype, donc je connais la plupart des problèmes. Comme mentionné précédemment, seuls les supports pour GET et POST sont disponibles. À première vue, il semble que vous puissiez utiliser la configuration du proxy dans LiveCycle Data Services ou Blaze pour obtenir une assistance pour PUT et DELETE. Cependant, c'est un simulacre. La demande provenant de votre application Flex sera toujours un POST. Le proxy le convertit en PUT ou DELETE côté serveur pour tromper votre code côté serveur. Il y a aussi d'autres problèmes. On entend croire que c’est le meilleur choix d’Adobe. Après mon évaluation, nous avons décidé d'aller dans une autre direction.
Oui, j'ai pu utiliser les en-têtes POST et d'accès avec ce composant:
Je travaille actuellement sur une application qui repose largement sur les appels REST entre Flex, JavaScript et Java Servlets. Nous contournons le problème du code d'erreur de réponse en établissant une convention de & Status id = & "XXX &"; name = " YYYYYY " > bloc renvoyé en cas d'erreur, avec des ID d'erreur mappés en gros aux codes d'erreur HTTP.
Nous avons contourné les limitations de scriptage intersite en utilisant un servlet Java en tant que proxy HTTP. Les appels au proxy (qui s'exécute sur le même serveur que le reste du contenu, y compris le contenu Flex, envoient la requête à l'autre serveur, puis renvoient la réponse à l'appelant initial.
RestfulX a résolu la plupart / tous les problèmes. les problèmes REST avec Flex. Il prend en charge Rails / GAE / Merb / CouchDB / AIR / WebKit et je suis sûr que ce serait un jeu d'enfant de le connecter à votre implémentation Java.
Dima a également intégré la bibliothèque AS3HTTPClient.
Découvrez-le!
En fait, nous utilisons déjà Flex avec une structure Rest-Style. Comme mbrevort déjà mentionné, les méthodes PUT et DELETE ne peuvent pas être utilisées directement. Au lieu de cela, nous faisons PUT via un POST et pour DELETE, nous utilisons un GET sur une ressource avec un paramètre d'URL tel que? Action = delete.
Ce n'est pas un style 100% Reste, je ne suis donc pas sûr que cela fonctionne avec une implémentation JSR 311. Pour résoudre le problème des restrictions PUT et DELETE, vous aurez besoin d’une certaine souplesse du côté serveur.
En ce qui concerne le traitement des erreurs, nous avons mis en place un service d’erreur. En cas d'erreur côté serveur, l'application Flex peut interroger ce service d'erreur pour obtenir le message d'erreur réel. C’est aussi beaucoup plus souple que de simplement mapper les codes de retour HTTP en messages statiques.
Cependant, grâce au script ECMA de Flex, l'utilisation de services REST basés sur XML est très simple.
REST est plus une idéologie que n'importe quoi. Vous allez aux présentations REST et ils ont des distributeurs de coolaide.
Pour les applications Flex, il est plus pratique et plus performant de faire rouler une pile en association avec le marshalling de données BlazeDS et AMF.
Par le passé, j'ai utilisé un proxy PHP qui gère les appels de service Web à distance et renvoie le code RTU JSON au client.
Peut-être que le nouveau flex 4 est la réponse http://labs.adobe.com/technologies / flex4sdk /
Le livre Rails flexibles peut être utile. C'est une excellente ressource pour savoir comment utiliser Flex en tant que client RESTful. Bien qu'il se concentre sur l'utilisation de Flex avec le framework Rails, je pense que les concepts s'appliquent à tout framework RESTful. J'ai utilisé ce livre pour apprendre rapidement à utiliser Flex avec REST.
Je travaille sur un grand projet Flex pour Franklin Covey. Nous utilisons les services REST. Afin de soutenir cela. Nous avons créé un wrapper XMLHttpRequest. En utilisant une interface externe avec certains gestionnaires d'événements. Nous avons ouvert la bibliothèque. Vous pouvez le vérifier à l'adresse https://github.com/FranklinCovey/AS3-XMLHttpRequest
