Skip to content

Fix issues with openapi spec#9429

Open
tylerjmchugh wants to merge 1 commit into
geonetwork:mainfrom
tylerjmchugh:fix-openapi-spec
Open

Fix issues with openapi spec#9429
tylerjmchugh wants to merge 1 commit into
geonetwork:mainfrom
tylerjmchugh:fix-openapi-spec

Conversation

@tylerjmchugh

Copy link
Copy Markdown
Contributor

Some API endpoints currently use HttpStatus as their response body type even though they do not return a response body. This causes OpenAPI to interpret HttpStatus as response content and generate an enum schema containing the possible status values.

The harvester reindex endpoint is also currently documented with both 200 and 204 success responses, even though it returns 204.

In addition, the DOI server and mapserver delete endpoints currently have conflicting generated operation IDs. This causes the generated _1 suffix to switch between the endpoints depending on their order in the OpenAPI specification, resulting in unstable generated client method names.

This PR aims to fix these issues by:

  • Replacing ResponseEntity<HttpStatus> and HttpEntity<HttpStatus> with ResponseEntity<Void> for endpoints that do not return a response body. The response status continues to be set through the ResponseEntity, while Void correctly indicates to OpenAPI that the response does not contain content.
  • Removing @ResponseStatus(HttpStatus.OK) from the harvester reindex endpoint so that 204 is the only documented success response.
  • Adding explicit deleteDoiServer and deleteMapserver operation IDs to prevent conflicts and keep the generated method names stable.

Checklist

  • I have read the contribution guidelines
  • Pull request provided for main branch, backports managed with label
  • Good housekeeping of code, cleaning up comments, tests, and documentation
  • Clean commit history broken into understandable chucks, avoiding big commits with hundreds of files, cautious of reformatting and whitespace changes
  • Clean commit messages, longer verbose messages are encouraged
  • API Changes are identified in commit messages
  • Testing provided for features or enhancements using automatic tests
  • User documentation provided for new features or enhancements in manual
  • Build documentation provided for development instructions in README.md files
  • Library management using pom.xml dependency management. Update build documentation with intended library use and library tutorials or documentation

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant