2012-11-13 5 views
24

Tra tutte le possibilità per tornare una risposta al cliente in un servizio diREST, ho visto due possibilità che sembrano equivalenti: Lancio del WebApplicationException (possibilmente utilizzando un'istanza Response) o di ritorno un'istanza Response.WebApplicationException vs risposta

Perché utilizzare una possibilità rispetto all'altra poiché il risultato è lo stesso? Questo è collegato al framework REST utilizzato che può essere configurato per reagire in modo diverso tra eccezioni e risposte regolari?

+1

Vedo 'WebApplicationException' come un caso di errore piuttosto che un caso di successo. Se si dispone di un metodo che normalmente restituisce (ad esempio) un oggetto JAXB nel caso di successo, lanciando una 'WebApplicationException' fornisce un modo per restituire un altro tipo di dati nel caso di errore. Ma se il metodo è dichiarato per restituire 'Response' nel caso di successo, allora c'è meno bisogno dell'approccio di eccezione. –

+1

Dai un'occhiata alla [documentazione di Jersey] (http://jersey.java.net/nonav/documentation/latest/jax-rs.html#d4e435) per alcune idee su 'Response' rispetto a' WebApplicationException'. Per il successo, usa sempre 'Risposta'. –

+0

@IanRoberts Capisco il fatto che uno è generalmente utilizzato per i guasti e l'altro per gli scenari di successo. Ma la mia domanda è più tecnica, cioè c'è una differenza su come la risposta viene interpretata o elaborata dal framework se si tratta di un'eccezione o di una risposta regolare? (Ho aggiunto il tag Jersey). –

risposta

22

Perché utilizzare una possibilità rispetto all'altra poiché il risultato è lo stesso?

Forse perché come programmatore (Java) si è abituati a lanciare eccezioni quando si rompono particolari regole dell'applicazione? Converti una stringa in un numero e potresti ottenere un NumberFormatException, utilizzare un indice sbagliato in un array e ottieni un ArrayIndexOutOfBoundsException, accedere a qualcosa che non ti è permesso e ottenere un SecurityException ecc. Sei abituato a generare eccezioni quando la "risposta regolare" "non può essere creato (sia da un input sbagliato o da un errore di elaborazione).

Quando non è possibile restituire la risposta regolare, è necessario restituire una risposta di errore al client. Puoi farlo eliminando l'eccezione o costruendo la risposta a mano. È la stessa cosa per il tuo cliente, ma non è la stessa cosa per il tuo codice lato server.

Lanciare l'eccezione rende il codice più pulito, più facile da ragionare e quindi più facile da capire. L'idea è di sottoclasse lo WebApplicationException e di creare le proprie eccezioni significative (ad esempio ProductNotFoundException extends WebApplicationException { ... }, AccessDeniedException extends WebApplicationException { ... } o riutilizzare le eccezioni con un exception mapper).

E 'quindi più pulito per throw new ProductNotFoundException() o throw new AccessDeniedException() e lasciare gestire il quadro è invece di costruire un Response ogni volta e poi seguire le informazioni utilizzate per costruirlo per capire cosa sta succedendo in quella sezione di codice.

+8

C'è un altro motivo per lanciare un'eccezione: se si stanno utilizzando le transazioni, consente al contenitore di eseguire il rollback delle modifiche apportate in precedenza ai dati all'interno di tale richiesta. Se restituisci una risposta regolare, dovrai prenderti cura di te stesso. –

+0

cosa intendi con "lasciare che sia il framework a gestirlo"? Avete qualche articolo a cui posso riferire per come funziona? Grazie. – Cacheing

+0

@Cacheing: [Le specifiche JAX-RS] (http://download.oracle.com/otndocs/jcp/jaxrs-1.1-mrel-eval-oth-JSpec /) indica come deve essere gestita WebApplicationException. È anche possibile registrare un provider di mapping delle eccezioni, descritto anche nelle specifiche. – Bogdan

Problemi correlati