Come gestire le eccezioni del binding automatico con Jersey?

Question

Come gestire le eccezioni del binding automatico con Jersey?

#1 da (1 voti)

0

È davvero bello avere un binding automatico con Jersey-Jackson (beh, credo che sia in realtà MOXy colui che gestisce i binding), quindi la serializzazione degli oggetti e la deserializzazione sono fatti sotto il cofano.

Esempi di entrambi quelli che uso nel mio servizio RESTful:

@POST
@Consumes(MediaType.APPLICATION_JSON)
public String createTournament(Tournament tournament) {
    return tournamentDao.create(tournament);
}

@Path("/{id}")
@GET
@Produces(MediaType.APPLICATION_JSON)
public Tournament getTournament(@PathParam("id") String id) {
    Optional<Tournament> optTournament = tournamentDao.getTournament(id);
    if (optTournament.isPresent())
        return optTournament.get();
    throw new NotFoundException();
}

Ma cosa succede se la serializzazione o la deserializzazione falliscono in qualche momento durante il processo? Ad esempio, campi sconosciuti, tipi errati, formato JSON illegale, ecc ... Beh, non posso occuparmene perché la serializzazione / deserializzazione sta accadendo dietro le quinte e tutto quello che so è che otterrò un argomento di tipo Tournament (o restituirlo nell'altro caso) ma questo presuppone che il processo abbia successo.

Come posso affrontare questo? Cosa accadrebbe se volessi restituire un altro tipo di risposta per un JSON di torneo mal formattato invece di generare un'eccezione durante un punto molto particolare della serializzazione / deserializzazione?

È possibile? Inoltre, qual è l'approccio standard per questi scenari? Quale risposta sarebbe appropriata per un errore durante l'elaborazione JSON?

java rest http json web-services

posta dabadaba 22.06.2016 - 15:59

fonte

1 risposta

Leggi altre domande sui tag java rest http json web-services

Come modificare una parte specifica di un colore dell'immagine? [chiuso] È corretto dire che i thread consentono ai programmatori di esporre i processi interni allo scheduler del SO?

score 1 · Accepted Answer

Il codice di errore HTTP corretto sull'input è 400: Bad Request. Nella risposta potresti andare con 500.

Se c'è un errore nel marshalling o unmarshalling, verrà lanciata un'eccezione che puoi gestire registrando un ExceptionMapper (scorri verso il basso nella sezione Mappatura delle eccezioni). È quindi possibile determinare quale tipo di errore generare. Il pacchetto JAX-RS ha una classe WebApplicationException che consente di restituire i codici di errore HTTP comuni. Se hai bisogno di essere davvero fantasioso, puoi utilizzare ResponseBuilder per perfezionare la risposta.

Personalmente trovo molto utile scrivere javax.ws.rs.core.Application e sovrascrivere il metodo getClasses () in questo modo:

public Set<java.lang.Class<?>> getClasses()
{
    Set<Class<?>> classes = new HashSet<>();

    /* add filters */
    classes.add(AuthorizationFilter.class);
    /* add resources */
    classes.add(HomeResource.class);
    classes.add(RequestsResource.class);

    /* add object serializers */
    classes.add(JsonMarshaller.class);
    classes.add(HtmlWriter.class);

    return classes;
}

Inserisci Jersey in un'applicazione Jetty integrata (o simile) se vuoi essere privo di XML.

Questo richiederà molto del mistero su come funzionano le cose. Il tipo di problema che stai incontrando è il motivo per cui tendo ad evitare il pacchetto "Abbiamo fatto tutto per te in modo da non doverlo capire" per JAX-RS. Se implementi le tue classi MessageBodyReader e MessageBodyWriter, puoi comunque utilizzare un pacchetto che fa tutto il lavoro pesante ma che ha il controllo su questo tipo di dettagli.