We should therefore change our sample app accordingly.
Please note that maintaining things like this makes it hard while we have multiple feature branches (DAO vs. spring-data). Feel free to discuss our strategy. I am also happy to concentrate one one suggested scenario (spring-data?) and do not maintain other branches until we have reached some accepted stability.
Also some remark that I already put somewhere as review feedback but could not find anymore: We are using
javax.ws.rs.core.Response
as direct return type in REST services (see https://github.com/devonfw-forge/devonfw-microservices/blob/main/reference-project/src/main/java/com/devonfw/demoquarkus/rest/v1/controller/AnimalRestController.java). IMHO this is also an anti-pattern as it hiding the API. With this you cannot generate an OpenAPI contract from the code and you cannot see as a developer what is actually returned. In devon4j we have the best practice to always use clear signatures and make it obvious what is going in as parameter and what is going out as return type (see e.g. https://github.com/devonfw/devon4j/blob/master/documentation/guide-rest.asciidoc#jax-rs).We should therefore change our sample app accordingly. Please note that maintaining things like this makes it hard while we have multiple feature branches (DAO vs. spring-data). Feel free to discuss our strategy. I am also happy to concentrate one one suggested scenario (spring-data?) and do not maintain other branches until we have reached some accepted stability.