servicio - soap web service java

¿Por qué utilizar un marco para servicios RESTful en Java en lugar de servlets de vainilla?

Question

Sé que hay algunas preguntas con respecto a las bibliotecas que puede usar para hacer servicios RESTful en Java, pero cuál es el valor de usarlas contra implementaciones de vainilla. Quiero decir, si estaba buscando crear la estructura url descrita por Wim

• www.example.com/images
• www.example.com/images/id/num
• www.example.com/images/tag/num
• www.example.com/images/tag/num/num/num

¿No sería más fácil (para futuros desarrolladores) y más rápido (implementar y aprender) mapear el patrón / imágenes de url a un servlet y tener una o dos líneas que analicen la url para los parámetros en lugar de aprender, implementar y configurar uno de Estas bibliotecas lo hacen por ti.

• Apache CXF
• Jersey (popular)
• Restlet (pionero de JAX-RS)
• RESTEasy

Esencialmente, lo que estoy preguntando es ... ¿Cuál es el valor de usar un marco Java RESTful? ¿No estaría agregando mucha complejidad, en la implementación, para un problema simple?

EDITAR: Este código de camiseta se maneja muy bien y todos deben saber cómo hacerlo en forma de servlet si buscan bibliotecas para hacerlo por ellos.

@Path("/helloworld")
public class HelloWorldResource {

    // The Java method will process HTTP GET requests
    @GET
    // The Java method will produce content identified by the MIME Media
    // type "text/plain"
    @Produces("text/plain")
    public String helloWorld() {
        // Return some cliched textual content
        return "Hello World";
    }
}

Si todo lo que va a hacer es un "servicio" que devuelve el texto que está controlado por los parámetros de la URL, por lo tanto, ¿se necesita un marco?

Answer 1

¿No sería más fácil (para futuros desarrolladores) y más rápido (implementar y aprender) mapear el patrón /images url a un servlet y tener una o dos líneas que analicen la url para los parámetros en lugar de aprender, implementar y configurar uno de Estas bibliotecas lo hacen por ti.
...

¿Más fácil? Ciertamente, no es más fácil de escribir: debe realizar la extracción de la ruta por sí mismo, el manejo del método y la negociación del tipo de contenido (en ambas direcciones) y el manejo de las cookies y los procesos de deserialización / serialización de objetos y ... bueno, muchas cosas de bajo nivel que necesitarían pruebas y depuración, o más fáciles de mantener, ya que la interfaz JAX-RS le permite operar en el nivel de los recursos (la caracterización natural de las aplicaciones web RESTful) en lugar de las solicitudes; con mucha experiencia, el mantenimiento es más fácil cuando la brecha entre el modelo conceptual y la implementación es menor. Tampoco es más rápido de implementar (porque las implementaciones de bajo nivel de JAX-RS ya han sido probadas y depuradas para usted; menos para usted) y el costo de aprendizaje no es muy alto, ya que es una API en su mayoría declarativa. Con muy pocas sorpresas.

De acuerdo, es posible que estos beneficios no parezcan mucho cuando solo se trata de aplicaciones web simples. Después de todo, puedes piratear algo en muy poco tiempo y poner en línea el juego resultante. Luego tendrás que rezar para que lo hayas hecho bien, sin avenidas significativas e inesperadas para ataques o ataques de denegación de servicio. Y los programadores de mantenimiento tendrán que entender exactamente lo que hacen esas expresiones regulares que has rociado a través del código (¡Buena suerte con eso!) Al agregar características pequeñas o corregir errores. Pero a medida que la aplicación web se hace más grande, el beneficio de tener una biblioteca probada para manejar todo el contenido de bajo nivel realmente gana.

(Antes de que preguntes, algunas de las bibliotecas que mencionas se instalarán alegremente como servlets; esto permite que tu código describa simplemente la lógica de negocios del servlet y declare cómo la asignación al cable se realiza en términos abstractos. Eso es mucho más fácil).

Answer 2

JAX-RS es una API muy bien diseñada que hace que la asignación de solicitudes HTTP a métodos, la extracción de parámetros de varias partes de una solicitud HTTP, el manejo de la negociación del contenido y muchas otras tareas de bajo nivel sean muy fáciles.

Usando JAX-RS, principalmente a través de Apache CXF, desde hace aproximadamente dos años, siempre lo preferiría a los Servlets simples.

Answer 3

Los marcos se utilizan para hacer su tarea más fácil. Estoy de acuerdo en que podemos hacer lo mismo implementando servlets y luego analizar la url y luego implementar la lógica básica.

Pero si está utilizando un marco como el jersey, no tiene que preocuparse por esos patrones de análisis y otras tareas similares. La clase ServletContainer se encargará de esto (analizar la url en su método de servicio) y también hay muchas otras clases que facilitarán su tarea.

Y una cosa más es que estamos tomando solo un escenario (patrones coincidentes), pero cuando nuestros requisitos crezcan, el mismo código escrito por nuestros propios servlets se volverá más complicado y complejo.

Answer 4

Me gustaría usar Jersey o una biblioteca en este caso, si hace lo siguiente (agrega suficiente valor):

• La configuración de la URL es completamente autónoma dentro de un archivo, con la fuente
• no hay archivos de configuración ocultos o configuraciones demasiado detalladas (por ejemplo, web.xml)
• los parámetros están bien mapeados a variables fuertemente tipadas (por ejemplo, uso de anotaciones)
• no es complicado llegar a los valores de los parámetros (por ejemplo, RESTlet )
• la sobrecarga para ejecutar la biblioteca es baja (he tenido malas experiencias con soluciones de reflexión en otras bibliotecas)
• esta bien documentado
• esta bien adoptado

En tal escenario, encuentro que usar una biblioteca agregaría valor a mi proyecto por el esfuerzo requerido para usarlo. Jersey parece cumplir con los requisitos de manera bastante adecuada, aunque todavía no he investigado lo suficiente sobre otros marcos.