2008-09-30 35 views
32

Estoy comenzando un proyecto usando una arquitectura Restful implementada en Java (usando el nuevo estándar JAX-RS)¿Es factible crear un cliente REST con Flex?

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?

Respuesta

23

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 IBM Developer Works article from August 2008 de Jorge Rasillo y Mike Burr muestra cómo hacer una aplicación de fondo Flex front-end/RESTful (ejemplos en PHP y Groovy). Buen articulo. De todos modos, aquí está el llevar:

  • Su PHP/código Groovy usos 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 esto es no el método Proxy descrito 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';

¿Qué está pasando aquí? el servidor web de IBM intercepta e interpreta el "POST con BORRADO" como un BORRAR.

Por lo tanto, profundicé más y encontré este post and discussion with Don Box (uno de los tipos 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, sinceramente, se preguntan por qué me molesto en el uso de BORRAR y poner métodos en absoluto dado que X-HTTP-Method-Override se va a trabajar en más casos/despliegues."

Mi conclusión es que si su lado web admite este encabezado X-Method-Override, entonces puede utilizar este enfoque. Los comentarios de Don Box me hacen pensar que es bastante compatible, pero tengo no se ha confirmado que aún

Otro problema surge en torno a ser capaz de leer los encabezados de respuesta HTTP Una vez más, desde a blog post in 2007 by Nathan de Vries, vemos esto discutió siguió esa entrada en el blog y la discusión con su propio comentario:...

"El único cambio en el frente web es que las versiones más recientes de Flash Player (sin duda, esos s upplied con Flex 3 beta) ahora es compatible con la propiedad responseHeaders en instancias de HTTPStatusEvent. "

Espero que eso signifique que no es un problema ahora.

+0

Creo que también es importante preguntarse si los clientes que usan "X-HTTP-Method-Override" pierden algunos de los beneficios de REST. ¿Es este enfoque realmente diferente de tunelización sobre HTTP? ¿No pierde la capacidad de aprovechar proxies de almacenamiento en caché y otras ventajas similares? – Gili

+0

Si mira aquí http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html en la sección 13.10 verá que PUT, DELETE y POST causan que una entrada de caché sea invalidada. Por lo tanto, independientemente de si usa el verbo correcto o POST más X-HTTP-Method-Override, tendrá el mismo efecto en la caché. –

+0

@Gili Para responder a su primera pregunta, no, usted no pierde ninguno de los beneficios de REST. –

5

Existen deficiencias definidas de la capacidad de Flex para actuar como un cliente RESTful puro.

Los comentarios a continuación son de esta blog:

El problema es HTTPService clase tiene varias limitaciones importantes:

  1. métodos GET y POST son compatibles fuera de la caja solamente (a menos que utilice FDS y establezca el atributo useProxy en true)
  2. No se pueden establecer encabezados de solicitud y no hay acceso a la respuesta encabezados Por lo tanto, no puedo acceder al cuerpo de la respuesta en el caso de un error.
  3. HTTPService obtiene un código de estado cualquier cosa 200, se considera un error. (evento 201, ¡ay!). El FaultEvent no proporciona información sobre el código de estado de ninguna respuesta cuerpo. El cliente de Flex no tendrá idea de qué salió mal.

Matt Raible también dio una nice presentation on REST with Rails, Grails, GWT and Flex que tienen algunas buenas referencias vinculadas a ella.

Ya sea factible o no realmente depende de lo mucho que su dispuestos a trabajar alrededor de proxy, etc.

+0

Si estas limitaciones son correctas, entonces Flex no es un iniciador de REST en lugar de http. Poder acceder a todos los encabezados HTTP es crítico. –

0

En realidad fueron ya están usando Flex con un marco Resto-estilo. 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 ECMA scripting de Flex trabajando con servicios basados ​​en XML REST es muy fácil.

+1

que es RPC a través de HTTP y ni siquiera está cerca de REST –

+0

Bueno, algo intermedio. REST tiene 4 métodos, y dos de ellos deben implementarse de manera diferente ya que los verbos HTTP requeridos no están disponibles. – Yaba

1

estoy trabajando ahora mismo en una aplicación que se basa principalmente en las llamadas entre RESTO Flex y JavaScript y Java Servlets. Solucionamos el problema del código de error de respuesta estableciendo una convención de un < id de estado = "XXX" name = "YYYYYY" > bloque que se devuelve al error, con identificadores de error que se asignan de forma aproximada a los códigos de error HTTP.

Resolvemos las limitaciones de scripts entre sitios mediante el uso de un Servlet Java como un 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.

6

Como muchos han señalado HTTPService cabo es un poco simplista y no hace todo lo que quiere hacer. sin embargo, HTTPService es sólo azúcar por encima de las clases, como flash.net.*URLLoader, URLRequest y URLRequestHeader. el uso de estos se puede montar la mayoría de las peticiones HTTP.

Cuando se trata de admitir 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 se basa en el navegador para todos es una red.

0

REST es más una ideología que otra cosa. Vas a las presentaciones de REST y tienen dispensadores de coolaide.

Para aplicaciones Flex, enrollar una pila en conjunto con BlazeDS y clasificación de datos AMF es más conveniente y más eficiente.

+2

Guau, excelente, dime más. Amo a Koolaid. BTW, "más rendimiento" que qué? –

0

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 para el cliente ..

3

que he estado trabajando en un código abierto reemplazo para el componente HTTPService que admite completamente REST. Si está interesado, puede encontrar la versión beta (código fuente y/o compilado Flex biblioteca compartida en tiempo de ejecución) y las instrucciones aquí:

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

1

RestfulX tiene resolvió la mayoría/todos los problemas de 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's también ha integrado la biblioteca AS3HTTPClient.

¡Échale un vistazo!

2

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 básico de solicitud HTTP y la falta de PUT y DELETE a través del método rails-_? Method =. Tacky quizás, pero hace el trabajo bien.

me señaló algo del dolor cabeceras en una antigua entrada de blog en http://verveguy.blogspot.com/2008/07/truth-about-flex-httpservice.html

+0

method = xxx is RPC not REST –

+0

fuzzy: te está faltando el punto. el _method = hack es necesario para tratar con navegadores (y Flash Player) que no pueden realmente realizar llamadas PUT y DELETE reales. Rails ha usado la misma solución ... – verveguy

0

El libro Flexible Rails puede ser útil - Es un excelente recurso sobre el uso de Flex como un cliente REST. 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.

2

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.

0

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