java - tutorial - rest client with jersey
¿Es factible crear un cliente REST con Flex? (15)
Como muchos han señalado, HTTPService es un poco simplista y no hace todo lo que desea hacer. Sin embargo, HTTPService es solo azúcar sobre las clases flash.net.* Como URLLoader , URLRequest y URLRequestHeader . Utilizándolos, puede ensamblar la mayoría de las solicitudes HTTP.
Cuando se trata de soporte para otros métodos además de GET y POST, el problema radica principalmente en que algunos navegadores (por ejemplo, Safari) no los admiten, y Flash Player depende del navegador para todas sus redes.
Estoy comenzando un proyecto usando una arquitectura Restful implementada en Java (usando el nuevo estándar JAX-RS)
Estamos planeando desarrollar la GUI con una aplicación Flex. Ya he encontrado algunos problemas con esta implementación utilizando el componente HTTPService (los códigos de error de respuesta, el acceso a los encabezados ...).
Cualquiera de ustedes tiene alguna experiencia en un proyecto similar. ¿Es factible?
El libro Flexible Rails puede ser útil: es un excelente recurso sobre cómo usar Flex como cliente RESTful. Aunque se centra en el uso de Flex con el framework Rails, creo que los conceptos se aplican a cualquier marco RESTful. Utilicé este libro para ponerme al día rápidamente al usar Flex con REST.
El problema aquí es que muchas de las discusiones web sobre este tema tienen un año o más. Estoy trabajando en esta misma investigación en este momento, y esto es lo que aprendí hoy.
Este artículo de IBM Developer Works, de agosto de 2008, de Jorge Rasillo y Mike Burr muestra cómo hacer una aplicación de fondo flexible / RESTful de Flex (ejemplos en PHP y Groovy). Buen articulo. De todos modos, aquí está el llevar:
- Su código PHP / Groovy usa y espera PUT y DELETE.
- Pero el código Flex tiene que usar POST, pero establece el encabezado HTTP X-Method-Override para DELETE (puede hacer lo mismo para PUT I presume).
- Tenga en cuenta que este no es el método Proxy discutido anteriormente.
// 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 esta pasando aqui? el servidor web de IBM intercepta e interpreta el "POST con BORRADO" como un BORRAR.
Así que profundicé y encontré esta publicación y discusión con Don Box (uno de los chicos originales de SOAP). Aparentemente, este es un comportamiento bastante estándar, ya que algunos navegadores, etc. no admiten PUT y DELETE, y es una solución temporal que ha durado un tiempo. Aquí hay un fragmento, pero hay mucha más discusión.
"Si estuviera construyendo un cliente GData, honestamente me pregunto por qué me molestaría en usar los métodos DELETE y PUT en absoluto dado que X-HTTP-Method-Override va a funcionar en más casos / implementaciones".
Mi conclusión es que si su lado web admite este encabezado X-Method-Override, entonces puede usar este enfoque. Los comentarios de Don Box me hacen pensar que es bastante compatible, pero aún no lo he confirmado.
Otro problema surge cuando se pueden leer los encabezados de respuesta HTTP. Nuevamente, desde una publicación de blog en 2007 por Nathan de Vries , vemos esto discutido. Siguió esa publicación del blog y la discusión con su propio comentario:
"El único cambio en la web es que las versiones más recientes de Flash Player (ciertamente las que se suministran con la versión beta de Flex 3) ahora admiten la propiedad responseHeaders en instancias de HTTPStatusEvent".
Espero que eso signifique que no es un problema ahora.
El soporte de Flex para REST es débil en el mejor de los casos. Pasé mucho tiempo construyendo un prototipo, así que sé la mayoría de los problemas. Como se mencionó anteriormente, de fábrica solo hay soporte para GET y POST. A primera vista, parece que puede usar la configuración del proxy en LiveCycle Data Services o Blaze para obtener soporte para PUT y DELETE. Sin embargo, es una farsa. La solicitud proveniente de su aplicación Flex seguirá siendo un POST. El proxy lo convierte en PUT o DELETE en el lado del servidor para engañar al código del lado del servidor. Hay otros problemas también. Se ha escuchado creer que esto es lo mejor que Adobe podría haber logrado. Después de mi evaluación, decidimos ir en otra dirección.
En realidad, ya están usando Flex con un marco de estilo de descanso. Como mbrevort ya mencionó los métodos PUT y DELETE, no se pueden usar directamente. En cambio, estamos haciendo PUT a través de un POST y para DELETE estamos usando un GET en un recurso con un parámetro de URL como? Action = delete.
Esto no es 100% estilo de descanso, por lo que no estoy seguro, si esto funciona con una implementación JSR 311. Necesitará cierta flexibilidad en el lado del servidor para solucionar las restricciones PUT y DELETE.
Con respecto al manejo de errores, hemos implementado un servicio de error. En caso de un error del lado del servidor, la aplicación Flex puede consultar este servicio de error para obtener el mensaje de error real. Esto también es mucho más flexible que solo asignar códigos de retorno HTTP a mensajes estáticos.
Sin embargo, gracias a las secuencias de comandos de ECMA de Flex trabajando con servicios REST basados en XML es muy fácil.
Estoy trabajando ahora mismo en una aplicación que depende en gran medida de las llamadas REST entre Flex y JavaScript y Java Servlets. Solucionamos el problema del código de error de respuesta estableciendo una convención de un bloque <status id = "XXX" name = "YYYYYY>> que devuelve el error, con identificadores de error que se relacionan aproximadamente con los códigos de error HTTP.
Solucionamos las limitaciones de scripts entre sitios mediante el uso de Java Servlet como proxy HTTP. Las llamadas al proxy (que se ejecuta en el mismo servidor que sirve el resto del contenido, incluido el contenido de Flex, envía la solicitud al otro servidor y luego envía la respuesta al llamador original).
Existen deficiencias definidas de la capacidad de Flex para actuar como un cliente RESTful puro.
Los comentarios a continuación son de este blog :
El problema es que la clase HTTPService tiene varias limitaciones principales:
- Solo los métodos GET y POST se admiten de forma inmediata (a menos que use FDS y establezca el atributo useProxy en verdadero)
- No se pueden establecer encabezados de solicitud y no hay acceso a los encabezados de respuesta. Por lo tanto, no puedo acceder al cuerpo de respuesta en caso de error.
- HTTPService obtiene un código de estado nada más 200, considera un error. (evento 201, ¡ay!). FaultEvent no proporciona información sobre el código de estado de ningún cuerpo de respuesta. El cliente de Flex no tendrá idea de lo que salió mal.
Matt Raible también dio una buena presentación sobre REST con Rails, Grails, GWT y Flex que tienen algunas buenas referencias vinculadas a ella.
Si es factible o no, realmente depende de cuánto estés dispuesto a evitar con proxy, etc.
He estado trabajando en un reemplazo de código abierto para el componente HTTPService que es totalmente compatible con REST. Si está interesado, puede encontrar la versión beta (código fuente y / o biblioteca de tiempo de ejecución compartida compilada de Flex) e instrucciones aquí:
La forma en que he logrado esto en el pasado es utilizar un proxy PHP que se ocupa de las llamadas de servicio web remoto y devuelve RTU JSON al cliente.
La respuesta corta es sí, puede hacer RESTful con Flex. Solo tienes que evitar las limitaciones del reproductor Flash (mejor con las últimas versiones) y las limitaciones de la pila HTTP del navegador que lo contiene.
Hemos estado haciendo un desarrollo de cliente RESTful en Flex durante más de un año después de resolver el encabezado de solicitud HTTP básico y la falta de PUT y DELETE a través del método de rieles-esque? _method =. Tacky quizás, pero hace el trabajo bien.
Noté algunos de los dolores en los encabezados en una vieja publicación de blog en http://verveguy.blogspot.com/2008/07/truth-about-flex-httpservice.html
Puede ser el nuevo flex 4 es la respuesta http://labs.adobe.com/technologies/flex4sdk/
REST es más una ideología que nada. Vas a las presentaciones de REST y tienen dispensadores de coolaide.
Para las aplicaciones de Flex, hacer rodar una pila junto con la clasificación de datos de BlazeDS y AMF es más conveniente y más eficiente.
Sí, pude usar POST y acceder a los encabezados con este componente:
Trabajo en un gran proyecto flexible para Franklin Covey. Usamos servicios REST. Para apoyar esto Creamos un contenedor XMLHttpRequest. Mediante el uso de una interfaz externa con algunos controladores de eventos. Abrimos la biblioteca. Puede verificarlo en https://github.com/FranklinCovey/AS3-XMLHttpRequest
RestfulX ha resuelto la mayoría de los problemas REST con Flex. Tiene soporte para Rails / GAE / Merb / CouchDB / AIR / WebKit, y estoy seguro de que sería muy fácil conectarlo a su implementación de Java.
Dima también ha integrado la biblioteca de AS3HTTPClient en él.
¡Echale un vistazo!