Spring Boot中POST请求参数无法映射至非POJO的SpotDTO问题

Hey there, let's work through this frustrating issue where your SpotDTO is coming in with all null fields even though you've got all the getters and setters set up. I've run into similar scenarios before, so let's break down the most likely fixes step by step:

1. Verify You're Using the Right Annotation for Request Mapping #

Spring handles different request content types differently, so this is a super common misstep:

• If you're sending JSON data (Content-Type: application/json), you must annotate the DTO parameter with @RequestBody in your controller method:

  @PostMapping("/spots")
  public ResponseEntity<String> createSpot(@RequestBody SpotDTO spotDTO) {
      // Your logic here
  }
  

• If you're sending form data (Content-Type: application/x-www-form-urlencoded or multipart/form-data), use @ModelAttribute (or omit it, since it's the default for form data):

  @PostMapping("/spots")
  public ResponseEntity<String> createSpot(@ModelAttribute SpotDTO spotDTO) {
      // Your logic here
  }
  

Mixing these up (like sending JSON without @RequestBody) will almost always result in null fields.

2. Ensure SpotDTO Has a No-Argument Constructor #

Spring relies on a no-arg constructor to instantiate your DTO class. Even if you have a parameterized constructor, you need to explicitly define a no-arg one:

public class SpotDTO {
    // Required for Spring to instantiate the class
    public SpotDTO() {}

    // Your fields
    private String spotName;
    private double latitude;

    // All your getters and setters
    public String getSpotName() { return spotName; }
    public void setSpotName(String spotName) { this.spotName = spotName; }
    // ... other getters/setters
}

Without this, Spring can't create an instance of your DTO, leading to null fields.

3. Check Field Name Matching Between Request and DTO #

Spring uses name matching by default, so make sure your request parameter names exactly match the DTO's field names (case-sensitive for JSON, case-insensitive for form data in most setups):

• If your request uses snake_case (e.g., spot_name) but your DTO uses camelCase (spotName), you can either:
  • Add @JsonProperty("spot_name") to your DTO field to map it explicitly:

    @JsonProperty("spot_name")
    private String spotName;
    

  • Or set a global naming strategy in application.properties to convert snake_case to camelCase automatically:

    spring.jackson.property-naming-strategy=SNAKE_CASE
    

4. Rule Out Final Fields or Incorrect Access Modifiers #

If any of your DTO fields are marked final, Spring won't be able to set their values via setters. Ensure all fields are private (or package-private) and non-final:

// Bad - final field can't be set by Spring
private final String spotName;

// Good - mutable field with setter
private String spotName;

5. Confirm the Request is Actually Sending Parameters #

Before blaming Spring, double-check that your request is properly sending the parameters:

• Use tools like Postman, curl, or browser dev tools to inspect the request body. For example, a valid JSON request body should look like:

  {
      "spotName": "Central Park",
      "latitude": 40.785091
  }
  

• If the request body is empty or has typos in parameter names, your DTO will naturally have null fields.

6. Check for Custom MessageConverter Conflicts #

If you've configured custom HttpMessageConverter beans (e.g., for XML or custom JSON parsing), you might have overridden Spring's default converters. Make sure you're including the Jackson JSON converter (for JSON requests) in your configuration:

@Configuration
public class WebConfig implements WebMvcConfigurer {
    @Override
    public void configureMessageConverters(List<HttpMessageConverter<?>> converters) {
        // Don't forget to add the default Jackson converter
        converters.add(new MappingJackson2HttpMessageConverter());
        // Your custom converters here
    }
}

Omitting this can prevent Spring from parsing JSON requests correctly.

Start with these checks—most of the time, the issue is one of these common oversights. Let me know if you hit any snags while testing these fixes!

内容的提问来源于stack exchange，提问作者payloc91