Perché utilizzare un framework per servizi RESTful in Java anziché servlet vaniglia

Question

So che ci sono alcune domande riguardanti le librerie che è possibile utilizzare per eseguire servizi RESTful in Java, ma qual è il valore nel loro utilizzo rispetto alle implementazioni vanilla. Voglio dire, se stavo cercando di creare 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

non sarebbe più facile (per gli sviluppatori futuri) e più veloce (per implementare e imparare) per mappare il formato URL/images a un servlet e ha una linea o due che analizza l'url per i parametri invece o f imparare, implementare e configurare una di queste librerie per farlo per te.

• Apache CXF
• Jersey (popolare)
• Restlet (pioniere della JAX-RS)
• RESTEasy

In sostanza quello che sto chiedendo è ... Qual è il valore in uso una struttura Java RESTful? Non aggiungerebbe molta complessità, nell'implementazione, per un semplice problema?

EDIT: questo codice jersey è gestito in modo molto ordinato e tutti dovrebbero sapere come farlo in forma servlet se stanno cercando nelle librerie di farlo per loro.

@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"; 
    } 
} 

Se tutti si sta per fare è un "servizio" che restituisce il testo che è guidato da parametri URL, quindi torna di testo, è necessario un quadro?

Answer 1

Non sarebbe più facile (per gli sviluppatori futuri) e più veloce (per implementare e imparare) per mappare il modello URL /images ad un servlet e avere una linea o due che analizza l'URL per i parametri invece di imparare, implementando e configurando una di queste librerie per farlo per te.
...

Più semplice? Non è certamente più facile da scrivere: devi eseguire autonomamente tutte le operazioni di estrazione del percorso e tutte le modalità di negoziazione del contenuto (in entrambe le direzioni) e tutte le operazioni di gestione dei cookie e di deserializzazione/serializzazione degli oggetti e ... beh, un sacco di cose di basso livello che avrebbero tutti bisogno di test e debug - o più facili da mantenere, dal momento che l'interfaccia JAX-RS consente di operare a livello di risorse (la naturale caratterizzazione di webapp RESTful) invece di richieste; con molta esperienza, la manutenzione è più semplice quando il divario tra modello concettuale e implementazione è minimo. Non è nemmeno più veloce da implementare (perché le implementazioni di basso livello di JAX-RS sono già state testate e debugate per te, meno per te da fare) e il costo di apprendimento non è molto alto in quanto è un'API per lo più dichiarativa con pochissime sorprese.

OK, questi vantaggi potrebbero non sembrare così tanto quando si tratta solo di semplici webapp. Dopotutto, puoi hackerare qualcosa in pochissimo tempo e mettere online il gioco risultante. Dovrai quindi pregare che tu abbia capito bene senza significative vie inattese per exploit o attacchi denial-of-service. E i programmatori di manutenzione dovranno capire esattamente quali sono le espressioni regolari che avete spruzzato attraverso il codice (Good Luck With That!) Quando aggiungete piccole funzionalità o correggendo bug. Ma man mano che la webapp diventa più grande, il vantaggio di avere una libreria testata per gestire tutte le cose di basso livello in realtà vince.

(Prima di chiedere, alcune delle librerie di cui parli sarà allegramente si installare come servlet, questo consente il codice per descrivere solo la logica di business del servlet e dichiarare come la mappatura al filo è fatto in termini astratti Questo è solo. enormemente più facile)

Answer 2

JAX-RS è un'API molto ben progettata che rende molto semplice la mappatura delle richieste HTTP ai metodi, l'estrazione di parametri da varie parti di una richiesta HTTP, la gestione della negoziazione del contenuto e molti altri compiti di basso livello.

Utilizzando JAX-RS, principalmente tramite Apache CXF, per circa due anni, lo preferirei sempre su servlet semplici.

Answer 3

I framework sono utilizzati per semplificare il compito. Sono d'accordo che possiamo fare la stessa cosa implementando servlet e quindi analizzare l'url e quindi implementare la logica di base.

Bu se si utilizza un framework come la jersey, allora non ci si deve preoccupare di quei pattern di analisi e di altri compiti simili. La classe ServletContainer si prenderà cura di questo (analizzando l'url nel suo metodo di servizio) e ci sono anche molte altre classi che renderanno più semplice il tuo compito.

E un'altra cosa stiamo prendendo solo uno scenario (modelli corrispondenti) ma quando i nostri requisiti cresceranno lo stesso codice scritto dai nostri servlet diventerà più complicato e complesso.

Answer 4

vorrei andare con l'utilizzo di Jersey o una libreria in questo caso, se lo fa il seguente (aggiunge valore sufficiente):.

• la configurazione per l'URL è tutto self-contained entro un file, con la fonte
• non ci sono file di configurazione nascosti o verbi config di ose (ad es. web.xml)
• i parametri sono ben mappati a variabili digitato forte (ad esempio l'uso di annotazioni)
• non è contorto raggiungere i valori dei parametri (es RESTlet)
• l'overhead per eseguire la libreria è bassa (ho avuto brutte esperienze con le soluzioni di riflessione in altre biblioteche)
• e 'ben documentato
• è ben adottato

in un tale scenario, trovo che l'utilizzo di una biblioteca avrebbe annuncio d valore al mio progetto per lo sforzo richiesto per usarlo. Sembra che Jersey soddisfi abbastanza bene i requisiti, anche se non ho ancora fornito altre indagini sufficienti.