Handling invalid PathVariables in Spring Boot

Question

Suppose I have a GET controller /api/product/{id} where id is an integer. What is the best way to handle requests with non-integer ids? At the moment Spring just throws a java.lang.NumberFormatException and returns a 400.

Answer 1

You can have path variable validation, assuming id should be a positive int value.

@GetMapping("/api/product/{id}")
public void getProduct(@PathVariable("id") @Min(value = 0) Integer id) {
    // ...
}

Read more above request validation here .

You can even try @Range if you know product id has some range of int value.

Answer 2

A 400 response seems appropriate given your statement that id is an integer.

If your objection is to Spring's handling of it, you could always make your path variable a String, do the number check yourself, and silently return a 400 or any other response you want.

@GetMapping("/api/product/{id}")
public ResponseEntity<Product> getProduct(@PathVariable("id") String s) {
    try {
       int id = Integer.parseInt(s);
       // valid integer id here, do normal work ...
    }
    catch(NumberFormatException nfe) {
       return ResponseEntity.status(400).build(); // or whatever error code you want
    }
}

Answer 3

Suppose I have a GET controller /api/product/{id} where id is an integer. What is the best way to handle requests with non-integer ids?

If /api/product/abcde is a resource without a current representation, then you should probably return a 404 Not Found , with an explanation of the error in the message body.

Status codes are meta data, the target audience of a status code are general purpose components that understand the "transfer documents over a network" domain. Here, you want to call attention to the spelling of the target-uri, and 404 is the appropriate way to do that.

410 Gone might be a reasonable alternative to 404.

A 404 status code does not indicate whether this lack of representation is temporary or permanent; the 410 (Gone) status code is preferred over 404 if the origin server knows, presumably through some configurable means, that the condition is likely to be permanent.

The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an event is common for limited-time, promotional services and for resources belonging to individuals no longer associated with the origin server's site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time -- that is left to the discretion of the server owner.

Note that both 404 and 410 are "cacheable by default", which is probably what you want in this case.