No primary or default constructor found for interface java.util.List Rest API Spring boot
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
The error No primary or default constructor found for interface java.util.List is a Jackson deserialization problem, not a Spring Boot startup problem. It usually appears when request payload mapping points at an interface or abstract type without enough type information. Once you understand where Spring delegates conversion, the fix is straightforward and repeatable.
Core Topic Sections
Why this error appears
Spring MVC uses HttpMessageConverter implementations to transform JSON into Java objects. In most Boot applications, Jackson does this conversion. Jackson can instantiate concrete classes such as ArrayList, but it cannot instantiate an interface directly unless a concrete target type is implied by the controller method signature or by annotations.
If your endpoint expects an object but receives a JSON array, or if generics are erased by a raw type, Jackson may attempt to create List itself and fail with the constructor error.
Reproduce the failure quickly
The failure can be reproduced with an intentionally incorrect contract where the controller expects a wrapper object while the client sends an array.
If the client sends this payload instead of the wrapper object, binding fails:
Fix pattern 1: align payload and controller type
If the API should accept a bare array, declare List<UserDto> directly in the endpoint.
If the API should accept a wrapper object, keep UserBatchRequest and require this JSON shape:
Consistency between method signature and request body shape resolves most cases.
Fix pattern 2: avoid raw collections and ambiguous DTO fields
Raw types remove generic element information and make conversion fragile. Prefer explicit generic types in DTOs and method parameters.
Also avoid interface fields in request DTOs when you do not need polymorphism. A concrete ArrayList<UserDto> field is acceptable if your contract is simple and you want strict mapping behavior.
Validation and error handling
Add validation to fail with useful messages instead of a generic deserialization stack trace. @Valid and bean validation annotations improve API diagnostics.
A global exception handler can return a stable error format for clients.
Contract tests that prevent regression
Create integration tests for both valid and invalid payload shapes. This keeps request contracts explicit during refactors.
When these tests run in CI, payload drift gets caught before deployment.
Common Pitfalls
- Sending a JSON array while the endpoint expects a wrapper object with a
usersproperty. - Declaring raw
Listtypes and losing element type information needed by Jackson. - Mixing interface fields and polymorphic payloads without explicit type metadata.
- Ignoring validation, which hides contract mistakes behind generic deserialization errors.
- Relying on manual testing only, instead of adding contract tests for payload shape.
Summary
- The constructor error usually indicates JSON shape mismatch or missing concrete type information.
- Align endpoint signatures and payload structure first, then add validation.
- Use explicit generics in request DTOs to keep mapping deterministic.
- Return clear error responses with a controller advice for malformed JSON.
- Add integration tests for request contracts to avoid regressions.

