I have a POJO model that contains lots of fields. When we generate OpenApi Swagger docs for external users, we only want to expose a subset of the fields. Is there a way to do that? We don't want to change the POJO to add #ApiModelProperty for each field.
Related
I have a REST API defined in a swagger.yaml. Inside there are all the fields with their specifications (eg: length, pattern, etc.). Is there a way in java to validate these fields according to their specifications without having to do it manually?
In this way I should go and set the annotation manually above each
field, I was looking for a library that would automate everything by
reading the rules on the swagger
Yes, the OpenApi tool generator is able to do that.
https://openapi-generator.tech/docs/generators/jaxrs-spec
If the option "useBeanValidation" is enabled (default value), then the javax.validation annotations will be generated in your jaxrs bean.
If you are trying to validate request bodies in controller level, you should check javax validation constrains https://docs.oracle.com/javaee/7/api/javax/validation/constraints/package-summary.html
There are plenty of annotations such as #NotNull, #Pattern #Max etc. which will do the job
I have a use case where I have one dto class that has all the data retrieved from a db call. I need to create different json formats using information from that class.
What is the best way to do this?.Also is there a way to do this with out making a code change everytime a new json format is needed ,something like storing the different json schemas in a persistence layer and then
do the mapping dynamically ?
I provide below my simple thoughts. Suppose you have a dto class say EmpDto which has data in relation to your database table model. If you want to create a json in way different way, then you create a separate object model like EmpJsonBean and annotate the Json annotations from Jackson framework. You have to populate the EmpJsonBean by taking required data from the EmpDto class. This way you can do it.
If you think of a design pattern so that you can have minimal impact, I would suggest for Adapter design pattern so that you can have a different json structure based upon the business need.
My team is evaluating adopting OpenAPI Generator for our project, and the ability to declaratively keep Spring MVC mappings in sync with the spec is attractive. However, much of Spring MVC's value comes from its ability to automatically resolve request information and provide it as strongly typed method parameters, and in the examples I've seen the generated Java interfaces only reflect the request attributes as directly listed in the spec. For example, userId is a string in a path mapping, and in my controller I want to inject that as a UUID or even a User (with DomainClassConverter). Additionally, I may want access to the HttpSession.
Is there any way (short of rewriting the templates) to customize the method parameters so that I can get the mappings autogenerated but add attributes for my own requirements?
I annotated my various controller methods with swagger Annotations but now I want to be able to retrieve the info for a given method programmatically, e.g. I want to retrieve the APIOperation value and notes from within Java. Is that possible without me checking through all the Swagger Annotations?
I'm working on a project that uses JAX-RS, Jackson, and JPA. The JAX-RS resources map incoming JSON directly to the POJO (JPA) that is to ultimately be persisted.
#POST
#Consumes(MediaType.APPLICATION_JSON)
public Response createEntity(Entity entity) {
...
}
However, I occasionally find that the information that a resource needs from the client doesn't cleanly map 1:1 to a POJO. There are extra fields that provide some metadata on how to handle the request. For example, a callback URL or a plaintext password that doesn't get persisted.
Is there an elegant way to perserve this information while still mapping directly to the JPA entity?
I have some ideas, but I'm not thrilled with any of them:
First map to a Map<String, Object>: Then use the ObjectMapper to map to an entity that is configured to ignore certain properties. This results in some extra boilerplate code for certain resources (possibly all resources that consume JSON for consistency's sake)
Use #Transient fields for extra values: This allows Jackson to map cleanly to POJOs, but tends to clutter the data model with business logic instead of just concerning itself with the state and behavior of entities.
Use #QueryParam for extra values: Seems to complicate the interface for the resource, and seems kind of arbitrary from a client perspective.
Any ideas? It would be nice if it were possible to rig a JAX-RS MessageBodyReader or some kind of context provider to pass a Map of the extra parameters as an additional argument to the method, but I don't know how much work this would be.
This use case is often handled by using dedicated data transfer objects at the resource level which will be mapped by frameworks like Dozer to the JPA entities. Besides the obvious boilerplate code, there are advantages of this approach:
If the resources follow the HATEOAS principle, the entities must be enriched with further REST specific information like their own link, links to other resources and pagination information.
Often REST clients have the option to specify entity expansion properties (which properties of the entity or referenced entities shall be included in the response for bandwidth reasons), where you would have to apply at least filters to the entities.
But coming back to your question, if you want to re-use the JPA entities for JSON mapping, I think your ideas are all valid. Another variant of your second idea may be to store all this extra information in a map as part of the entity (to have a single property as business logic clutter instead of many), if your JPA entities have a common base class this mapping can be done there. You can use the #JsonAnySetter annotation to achieve this.