Ignore specific properties conditionally (Support @JsonView)

[cemo]

I would like to hide some of my properties conditionally.

Usecase: I have an entity using at my rest controller with springfox at PUT and GET endpoints. At PUT endpoints I would like to hide id property whereas display at GET endpoints.

At first glance I have considered to use something like JsonView at jackson. What is the proper solution to implement this functionality without duplicating or extending bean?

[dilipkrish]

This feature isn't currently supported (jsonview). However, I would recommend that you not let the design of your system be dictated by a documentation library. Do what is right for your service and eventually the feature set of this library will catchup.

Having said that, would love to get your feedback on how you've decided to go forward and what the gaps are in this library.

[cbornet]

👍 for supporting this feature.

[gustavolira]

+1

[paolo-rendano]

+1

[AdelineJolie]

+1
@cemo I'm in the same case you and I will be interested to know what design did you adopt knowing this feature is not yet in springfox? Did you go for 2 two model input and output ?

[cbornet]

@AdelineJolie an alternative to JsonViews is to map DTOs to the model using a library such as mapstruct. (for information, mapstruct is used internally by springfox)
As I see it, supporting JsonViews in sprinfgfox is not an easy task as springfox would have to create a definition for each view with a unique name.
Would be a great feature, especially when a DTO is a bit overkill compared to a simple JsonView.

[dilipkrish]

I believe @mbazos is working on a related feature #182 which may help with partitioning request and response models as well.

[mbazos]

Yeah I am going to look into this tonight. Will post an update.

On Tue, Jan 12, 2016, 9:52 AM Dilip Krishnan notifications@github.com
wrote:

I believe @mbazos https://github.com/mbazos is working on a related
feature #182 #182 which
may help with partitioning request and response models as well.

—
Reply to this email directly or view it on GitHub
#807 (comment)
.

[AdelineJolie]

@cbornet Thank you for the answer!. Yes using DTOs and domain objects (coupled with a mapping lib) was going to be our last resort.
One of the other thing I tried was to use interfaces that I stick in the input and have my model implementing them (that I stick in the response) so I could still have single models. But I had trouble with spring's @requestbody with interfaces and an other problem was how to handle the hide/show on sub-object so in the end it was going to more complicated that simply using DTOs

@mbazos looking forward for this, thank you!

[kanouken]

so what about now ?

[dilipkrish]

@kanouken I don't think @mbazos is working on it any more. We're looking for contributions

[gazeciarz]

+1

[Szymaniuk]

+1

[adamzareba]

+1

[forsak3n]

+1

[MaksimOrlov]

Good afternoon.
I think, bean validation groups is the most convenient way to hide properties for the specific request.
Unfortunately, this could be applied only for requests.
Related question is being discussed at #1356.

[bananetomate]

+1

[semyon-zvyagin]

+1

[Diego-Rocha]

+1

[manuelhuber]

+1

[molexx]

What are people's current workarounds for this?

At the moment our swagger doc says a list operation returns a large model but actually only returns a few of those fields, and users have no way to tell which those fields are.

[MaksimOrlov]

Hi, @molexx

If I correctly understand your question:

There is one workaround with @ApiImplicitParams and you can use it with @ModelProperty(hidden = true)

So, if you use one Model with the lot of endpoints but you need to hide some properties conditionally, then the only way is to hide some property at the all endpoints and then add it by @ApiImplicitParams at the few specific endpoints.

For the return Models you can use @ApiOperation(response = Some.class) or @ApiResponse(response = Some.class) to override response Model. But, unfortunately, you will have to create all this classes with fields corresponding to the specific endpoint.

[molexx]

Thanks @MaksimOrlov, yes that's the problem.

@ApiImplicitParams and @ModelProperty will help in a couple of cases, thanks.

The return models are the problem, a hierarchy of inherited classes can help to a point but there always seem to be some properties which don't fit in.

I'm hoping that @JSONVIEW support will be straightforward to add when #1356 is done?

[zifnab87]

+1

[Kellym-Kainos]

+1

[varjasz]

+1

[td-ideabox]

+1

[beihaifeiwu]

+1

[mpataki]

+1

[deevodavis71]

+1

[StancuFlorin]

+1

[arcana261]

+1

[dovidkopel]

+1

[arnulfojr]

👍

[estevaojordao]

+1

[MikelDelTio]

+1

[saboteurkid]

After day searching and find a way to work on this problem. I've realized that I'd googled this problem about Swagger 2 Definition 1-2 years ago. So I think about it and decided this problem is the matter of design instead of @springfox (try to write a yaml that can serve your problem - You can't, right?).
I've taken a look around this repo (I'm totally new to Spring as well as SpringFox). There some discuss about @ApiModelProperty(hidden = true). I've tried it and it work just fine.
My solution for this problem:

1. Reconfig Jackson. example
2. Mark your protected properties with @ApiModelProperty(hidden = true) (Your DTO may look a bit messy but it's a fair trade off.)
3. Make use of Lombok so your class dont need boilerplate like setter, getter, equals, hashCode, toString.

Cheers!
P/s: Please stop comment +1. It's so annoying.

[molexx]

@saboteurkid if I'm understanding correctly, the problem with @ApiModelProperty(hidden = true) is that it applies all the time. The request is to make it conditional so that sometimes it applies and sometimes does not depending on context. My use case is @JsonView to hide some properties from a summary (list) response but include them in a detail response.

Yes swagger can't handle optionals, so multiple models have to be extrapolated from each class and added separately (with a new name) to swagger; I suspect that's partly why this is tricky.

[dilipkrish]

@saboteurkid thanks for providing a work around for all the +1s. Also, the next release will also have support for this.

[GregorioPerego]

@dilipkrish do you mean in the next release there'll be JsonView support? When is it scheduled?

[dilipkrish]

The next major release 3.0. Not scheduled yet.

[trautvetter]

+1

[pcoste]

@dilipkrish Do you have any news on the aviability of JsonView support or 3.0 ?

[dilipkrish]

@pcoste yes, @MaksimOrlov is working hard to help add support for that!

[pcoste]

@dilipkrish @MaksimOrlov Can we have an update on this highly expected feature ?
Thanks a lot.

[MaksimOrlov]

I'm almost finished with that, just found a little bug and I'm going to fix it on this week and make a little refactoring to accomplish style rules. Will push it at the weekend. Then if @dilipkrish approve changes they will be merged to master, then feature will be available at the shapshot version.

[pcoste]

Our next iteration start on March 11, dev team will try latest snapshot mid March and come back to you with some informations :)

Thanks

[MaksimOrlov]

@pcoste I've pushed changes. Waiting for feedback from @dilipkrish

[MaksimOrlov]

Branch with JsonView support has been merged to master and now available in 3.0.0-SNAPSHOT version. I would be grateful for feedback of this functionality.

[baizhantang]

This demand took four years to solve. Thank you! @MaksimOrlov

[Bipinkumar27]

This demand took four years to solve. Thank you! @MaksimOrlov

Do we have any example code for reference? If so please share I will be very helpfull