2012-01-08 15 views
13

Estoy al principio de una implementación REST y recientemente descubrí que podríamos poner nuestras anotaciones JAX-RS en nuestras interfaces de servicio Java en lugar de las implementaciones de clase.Anotaciones de JAX-RS: ¿es mejor instalar interfaces o clases?

Para mí, parece que esto podría dar como resultado un archivo de clase limpia, pero también podría dar lugar a que los desarrolladores tengan que mezclarse constantemente entre archivos.

¿Cuáles son los pros y los contras de cada enfoque?

+0

pregunta similar aquí: http://stackoverflow.com/questions/11427283/benifits-of-using-java-interfaces-in-jaxrs-web-services – Kirby

Respuesta

9

Debe ponerlo en una interfaz. Por el contrario, mi práctica me obliga a ponerlo en una interfaz, porque mi cliente y mi servidor comparten la misma definición de jax-rs.

Me inclino a usar jax-rs para REST-RPC.

El motivo de REST es permitir que una API de URL de servicio web sea útil y "clientable" por cualquier marco de programación.

El uso de jax-rs nos restringe a usar java en el lado del servidor.

El uso de jax-rs para REST-RPC nos restringe al uso de java tanto en el servidor como en el lado del cliente.

¿Qué es REST-RPC?

En una actitud de explicación no demasiado complicada, RPC es una forma de invocar una función/método en el cliente, que cuando se envía a través del cable es atendido por el servidor de modo que existe la misma función/método en el servidor .

RestEasy le permite usar la definición de jax-rs en el lado del cliente para llamar a la misma función atendida en el lado del servidor.

RestyGWT, también, con algunas modificaciones a la interfaz para especificar un método de devolución de llamada le permitiría (algo) utilizar la definición de jax-rs tanto del lado del cliente como del servidor. Simplemente tiene que escribir una secuencia de comandos para mover el tipo de devolución al argumento de tipo del método de devolución de llamada.

Podría preguntarse por qué restringirnos a realizar java en ambos lados? ¿Eso no derrotaría uno de los propósitos en la vida de REST? Creo que jax-rs REST-RPC es una ruta conveniente para implementar y probar un servicio jax-rs. Si quisiera implementar un servicio jax-rs, probablemente lo haría inicialmente en Java en ambos lados de todos modos. Y luego, cuando su servicio despegue, podría comenzar a escribir clientes PHP o Python.

Escribir sus jax-rs en archivos de interfaz le permitiría publicar su interfaz para las operaciones del lado del cliente. Esto es especialmente cierto para REST-RPC. Sin embargo, podría ejecutar enunciado sobre su definición de jax-rs para publicar su API de servicio web a programadores no java.

Tengo algunas excursiones en curso sobre este tema ... http://h2g2java.blessedgeek.com/2011/11/gwt-with-jax-rs-aka-rpcrest-part-0.html.

7

Creo que tengo que estar respetuosamente parcialmente en desacuerdo con Blessed Geek aquí. Lo que se menciona es un caso de uso muy específico que requiere el uso de anotaciones en la interfaz.

En mi propia experiencia, he encontrado casos en los que el marco, ya sea por diseño o por error, no responde correctamente al colocar anotaciones en la interfaz. Por ejemplo, Apache CXF no procesa adecuadamente las solicitudes @PUT con @PathParams definidas en la ruta cuando coloca las anotaciones en la interfaz. No me preguntes por qué.CXF no está solo en esto; Spring Security adolece de limitaciones similares al colocar anotaciones en las interfaces. Entonces este es un contrapunto al mencionado arriba.

En los casos donde usted es libre de elegir dónde colocar las anotaciones, Le insto a que considere lo que tiene sentido desde el punto de vista de la intención, el diseño y la facilidad de desarrollo.

Como argumento filosófico, algunas personas dicen que la colocación de anotaciones en las interfaces es otra forma de programación de contratos: usted dice que las implementaciones cumplirán con ciertas reglas.

La otra cara de la moneda (dependiendo de su definición de interfaces) es que a las interfaces no les deberían importar qué pasos tomen sus implementadores para lograr el objetivo definido en el contrato de método. Por ejemplo, ¿por qué colocar una anotación @Transactional en una interfaz cuando podría tener dos implementaciones, una de las cuales no tiene idea de lo que podría ser una "transacción"?

En la práctica, las líneas se vuelven borrosas. En el caso de definir un punto final relajante, puede preferir colocar las anotaciones adecuadas en la interfaz. Creo que esto tiene sentido en la mayoría de los casos; es probable que no tenga múltiples implementaciones donde la misma firma de método responda a diferentes verbos HTTP. Sin embargo, podría surgir una situación en la que diferentes implementaciones prefieran consumir y producir diferentes tipos de medios.

Entonces, la gran idea aquí es "depende". Pero espero que esto sea algo de reflexión para aquellos que puedan tropezar con esta pregunta.

2

Tuve una pregunta similar al usar JAX-RS con JAX-B. Mi esperanza era usar las anotaciones JAX-B en las interfaces, no en las clases. Esto no funciona como esperaba, la razón se debe al unmarshaller. Para resolver mis problemas, terminé usando clases. Here es una descripción de por qué y qué encontré.

Cuestiones relacionadas