Spring Data Rest: RequestBody for POST, PUT, PATCH should be required

[mathias-ewald]

Describe the bug
For POST, PUT, PATCH operations, the generated openapi specification does not mark the request body as required. I believe it should always be required for those operations. Event for PATCH it should just be at least {} rather an empty body.

To Reproduce
Spring Boot: 2.4.1
Springdoc: 1.5.4

Create a regular JPA repository and export it via Spring Data Rest, like:

public interface ProductRepo extends CrudRepository<Product, UUID> {}

Check api-docs.yaml:

$ curl http://localhost:8080/v3/api-docs.yaml
...
paths:
  /products:
    post:
      ...
      requestBody:
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/Product'
...

Expected behavior
The expected output is

paths:
  /products:
    post:
      ...
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/Product'

Additional notes
I have tried overriding the method signature like

	@Override
	<S extends Product> S save(@Param("entity") @RequestBody(required = true) S entity);

but the @RequestBody annotation is ignored.

[bnasslahsen]

@mathias-ewald,

I invite you to use all time the latest releases (v1.5.5) while reporting issues.

Note that:

• Only, search repositories, containing swagger-annotations are currently scanned.
• Overriding the CrudRepository using the swagger-annotations is not yet supported, as it is not likely the thing that is frequently customized through swagger-annotations: But, if you feel it useful for the community, please feel free to propose a PR.

Alternatively, note that you have a workaround using OpenApiCustomiser

This is a sample code:

@Bean
public OpenApiCustomiser requestBodyCustomiser() {
	return openApi -> openApi.getPaths().values().stream()
			.filter(pathItem -> pathItem.getPost()!=null || pathItem.getPut()!=null || pathItem.getPatch()!=null)
			.flatMap(pathItem -> pathItem.readOperations().stream())
			.filter(operation -> operation.getRequestBody() !=null)
			.forEach(operation -> operation.getRequestBody().setRequired(true));
}

I have made @RequestBody required by default which seems better.
This change will be available for the next release.

[mathias-ewald]

@bnasslahsen Sorry, I didn't realize 1.5.5 was there, yet.

Only, search repositories, containing swagger-annotations are currently scanned.

Can you clarify what you mean?

[bnasslahsen]

@mathias-ewald,

This is a sample code:

springdoc-openapi/springdoc-openapi-data-rest/src/test/java/test/org/springdoc/api/app21/PersonRepository.java

Lines 37 to 56 in 301f96d

	@RepositoryRestResource(collectionResourceRel = "people", path = "peopleme")
	public interface PersonRepository extends PagingAndSortingRepository<Person, Long> {
	@Operation(description = "this is my test")
	@ApiResponses(
	value = {
	@ApiResponse(responseCode = "200", description = "successful operation"),
	@ApiResponse(responseCode = "400", description = "Invalid ID supplied"),
	@ApiResponse(responseCode = "404", description = "Contact not found"),
	@ApiResponse(responseCode = "405", description = "Validation exception") }
	)
	List<Person> findByLastName(@Param("lastName") String name);
	@Operation(description = "this is another test", responses = {
	@ApiResponse(responseCode = "200", description = "another successful operation"),
	@ApiResponse(responseCode = "404", description = "another Contact not found") }
	)
	List<Person> findByFirstName(@Param("firstName") @Parameter(description = "this is for first Name") String name);
	}

The findByLastName and findByFirstName, generates search repositories: In their REST API resource patch, you will find /search.

For this kind of methods, the swagger annotations are scanned and already supported.

But if you override a method from CrudRepository and you add swagger annotations on it as you mentioned above, this will not be scanned.
At least, this is not supported (as it is less frequent) and this is the part, where a PR will can be welcome.

[mathias-ewald]

Ok, got it now 👍 Thanks for the explanations!