Que renvoyer si la méthode du contrôleur Spring MVC ne renvoie pas de valeur ?

Question

J'utilise l'outil jQuery $.getJSON() pour faire des appels asynchrones à mon simple backend Spring MVC. La plupart des méthodes du contrôleur Spring ressemblent à ceci :

@RequestMapping(value = "/someURL", method = RequestMethod.POST)
public @ResponseBody SomePOJO getSomeData(@ModelAttribute Widget widget,
    @RequestParam("type") String type) {
    return someDAO.getSomeData(widget, type);
}   

J'ai configuré les choses de manière à ce que chaque contrôleur renvoie le fichier @ResponseBody en tant que JSON, ce qui est ce que le côté client attend.

Mais que se passe-t-il lorsqu'une requête n'est pas censée renvoyer du contenu au côté client ? Je peux avoir :

@RequestMapping(value = "/updateSomeData" method = RequestMethod.POST)
public @ResponseBody void updateDataThatDoesntRequireClientToBeNotified(...) {
    ...
}

Si non, quelle est la syntaxe appropriée à utiliser ici ?

Answer 1

Vous pouvez renvoyer void, vous devez alors marquer la méthode avec @ResponseStatus(value = HttpStatus.OK) vous n'avez pas besoin de @ResponseBody

@RequestMapping(value = "/updateSomeData" method = RequestMethod.POST)
@ResponseStatus(value = HttpStatus.OK)
public void updateDataThatDoesntRequireClientToBeNotified(...) {
    ...
}

Seules les méthodes get renvoient un code d'état 200 implicite, toutes les autres font l'une des trois choses suivantes :

• Retourner void et marquer la méthode avec @ResponseStatus(value = HttpStatus.OK)
• Retourner un objet et le marquer avec @ResponseBody
• Retourner un HttpEntity instance

Answer 2

Vous pouvez simplement renvoyer une ResponseEntity avec l'en-tête approprié :

@RequestMapping(value = "/updateSomeData" method = RequestMethod.POST)
public ResponseEntity updateDataThatDoesntRequireClientToBeNotified(...){
....
return new ResponseEntity(HttpStatus.OK)
}

Answer 3

Vous pouvez renvoyer l'objet "ResponseEntity". L'utilisation de l'objet "ResponseEntity" est très pratique à la fois au moment de la construction de l'objet de réponse (qui contient le corps de la réponse et le code d'état HTTP) et au moment de l'extraction d'informations de l'objet de réponse.

Des méthodes comme getHeaders(), getBody(), getContentType(), getStatusCode() etc. facilitent la lecture de l'objet ResponseEntity.

Vous devriez utiliser l'objet ResponseEntity avec un code d'état http de 204(No Content), qui sert spécifiquement à indiquer que la demande a été traitée correctement et que le corps de la réponse est intentionnellement vide. Il est très important d'utiliser les codes d'état appropriés pour transmettre les bonnes informations, surtout si vous créez une API qui sera utilisée par plusieurs applications clientes.

Answer 4

Oui, vous pouvez utiliser @ResponseBody avec void type de retour :

@RequestMapping(value = "/updateSomeData" method = RequestMethod.POST)
@ResponseBody
public void updateDataThatDoesntRequireClientToBeNotified(...) {
    ...
}

Answer 5

Mais au fur et à mesure que votre système grandit en taille et en fonctionnalité... je pense que retourner toujours un json n'est pas une mauvaise idée du tout. C'est plus une question d'architecture / "conception à grande échelle".

On peut penser que le retour est toujours un JSON avec deux champs connus : code et data. Où code est un code numérique spécifiant le succès de l'opération à effectuer et data est toute donnée supplémentaire liée à l'opération / service demandé.

Allez, quand on utilise un backend, un fournisseur de service, n'importe quel service peut être vérifié pour voir s'il a bien fonctionné.

Je m'en tiens donc à ne pas laisser Spring gérer cela, en exposant des opérations de retour hybrides (certaines retournent des données, d'autres rien...)... et je m'assure plutôt que votre serveur expose une interface plus homogène. C'est plus simple à la fin de la journée.