Por qué usar 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 vanilla? Es decir, si yo estaba buscando para crear the url structure described by 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 (para poner en práctica y aprender) para mapear el patrón de URL/images a un servlet y tiene una línea o dos que analiza la url para los parámetros en su lugar o f aprender, implementar y configurar una de estas bibliotecas para que lo haga por usted.

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

Esencialmente lo que estoy pidiendo es ... ¿Cuál es el valor en el uso un marco de trabajo Java RESTful? ¿No agregaría mucha complejidad, en la implementación, a un problema simple?

EDITAR: Este código de jersey se maneja muy bien y todos deben saber cómo hacerlo en forma de servlet si están buscando en las bibliotecas que lo hagan 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á impulsado por parámetros de URL, por lo que los rendimientos de texto sin formato, es necesario un marco?

Answer 1

¿No sería más fácil (para futuros desarrolladores) y más rápido (para poner en práctica y aprender) para asignar el patrón de URL /images a un servlet y tienen una línea o dos que analiza la URL de los parámetros en lugar de aprendizaje, implementando y configurando una de estas bibliotecas para que lo haga por usted.
...

¿Más fácil? Ciertamente no es más fácil de escribir: tienes que hacer toda la extracción de ruta tú mismo y todo el manejo de métodos y toda la negociación de tipos de contenido (en ambas direcciones) y todos los procesos de manejo de cookies y los troncos 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 al nivel de los recursos (la caracterización natural de las aplicaciones web RESTful) en lugar de 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 aprenderlo no es muy alto, ya que es una API principalmente declarativa con muy pocas sorpresas

OK, estos beneficios pueden no parecer tanto cuando solo se trata de webapps simples. Después de todo, puedes hackear algo en muy poco tiempo y poner en línea el látigo resultante. Tendrás que rezar para que lo hagas bien sin importantes avenidas inesperadas para ataques o ataques de denegación de servicio. Y los programadores de mantenimiento tendrán que entender exactamente qué hacen esas expresiones regulares que has rociado a través del código (¡Buena suerte con eso!) Al agregar pequeñas características 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 todas las cosas de bajo nivel realmente gana.

(Antes de que pregunte, algunas de las bibliotecas que menciona se instalarán alegremente como servlets, esto permite que su código simplemente describa la lógica comercial del servlet y declare cómo se hace el mapeo en términos abstractos. enormemente más fácil)

Answer 2

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

Usando JAX-RS, principalmente a través de Apache CXF, durante 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.

Bu Si está usando framework como jersey, entonces no tiene que preocuparse por esos patrones de análisis y otras tareas similares. La clase ServletContainer se ocupará de esto (analizando 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 estamos tomando solo un escenario (haciendo coincidir los patrones), 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 ir con el uso de Jersey o una biblioteca en este caso, si se hace lo siguiente (agrega valor suficiente):.

• la configuración de la dirección URL es todo auto-contenida dentro de una archivo, con la fuente
• no hay archivos de configuración ocultos o demasiado verbo configuraciones de ose (p. web.xml)
• los parámetros están bien asignan a las variables inflexible de tipos (por ejemplo, uso de anotaciones)
• no se enrevesado para llegar a los valores de los parámetros (por ejemplo RESTlet)
• la sobrecarga para el funcionamiento de la biblioteca es bajo (he tenido malas experiencias con soluciones reflejo en otras bibliotecas)
• está bien documentado
• es bien adoptó

en tal escenario, me parece que el uso de una biblioteca sería ad d valor a mi proyecto por el esfuerzo requerido para usarlo. Jersey parece cumplir los requisitos de forma bastante adecuada, aunque todavía no he investigado suficientemente otros marcos.