What to return if a Spring MVC controller method doesn't return value?

Handlings in Spring MVC for non-returning values

Dealing with controller methods that perform actions without needing to return content? Maybe just updating some data or processing a monster-sized form submission (those exist, right 😅)? In these cases, use a void return type. It's Spring's silent nod to the client that everything went swimmingly. No content to return.

Gotta communicate the right HTTP status code though! A good example is a POST request that updates data but doesn't require a prize at the end - here, use a 204 No Content status to tell the client, "Hey, I've handled your request perfectly, but... I've got nothing for you."

A picture is worth 1000 words, and so is a POST method that returns void:

@PostMapping("/updateSomeData")
public void updateData(@RequestBody SomeData data) {
  // Process data here. Like a bartender with no free drink at the end.
}


Need to return an object? Has the client-side gone and demanded a JSON response? In this case, slap on the @ResponseBody annotation to the method.

@ResponseBody, assemble!:

@GetMapping("/data")
public @ResponseBody SomeObject retrieveData() {
  // Return a nice new object. It's like giving a wrapped gift!
  return new SomeObject();
}


For those times when control freakiness is at an all-time high and you need to define status and headers, go with ResponseEntity. It gives the power back to you!

ResponseEntity in the wild:

@PostMapping("/update")
public ResponseEntity<?> updateSomething(@RequestBody SomeData data) {
  // Logic here... it's like reading life's instruction manual first.
  return new ResponseEntity<>(HttpStatus.OK); // .ok(), .created(), adjust to your whims!
}


When JSON format has made itself home in your API, it's like everyone speaks the same language. Even when operations complete successfully with zip, zilch, zero to return, it's more consistent to send a JSON response. Even an empty one will do. Especially for asynchronous calls, like in $.getJSON(). Clients always expect predictability - and JSON formatted responses deliver just that!

The right return for client communication

Fine-tuning responses with ResponseEntity

ResponseEntity is like a Swiss Army knife - packed with tools for every situation. Make hand-crafted responses for your clients:

• Headers: Play around with cache settings, cookies or special headers
• Status code: Choose from any valid HTTP status code
• Body: If feeling generous, you can even include additional context

Correct status codes, every time!

Oh-so-important to ensure that the status codes for your API quit playing games and represent the response details truthfully. Some common statuses for non-return or void situations include:

• 200 OK: Standard response for absolutely smooth operations
• 201 Created: Indicates perfect creation, think of a POST operation
• 204 No Content: Perfect for situations where the job was done, and there's nothing to return
• 202 Accepted: Says, "Request is in queue, haven't started the job yet!"

Keeping API designs robust

Every application grows up and evolves one day (sorry, Peter Pan 😋) In terms of API consistency, clients shouldn't feel like they are on a rollercoaster. Here are some things to stick to:

• Uniformity: Status codes and response bodies should bear the same language
• Scalability: Future enhancements shouldn't throw the existing responses out of the window
• Documentation: Clients kindly demand documented responses and status codes for each endpoint