Support partial responses

[raderio]

Will be very useful to document that API support partial responses. This will give a strong point when comparing with GraphQL.

Like GET /api/blogposts?fields=author{name,avatar},title,detail

https://www.leliam.com/make-rest-api-to-partial-response-just-like-graphql-@bRyL6nWufIxFXIdNWRdAwN https://apigee.com/about/blog/technology/restful-api-design-can-your-api-give-developers-just-information-they-need

To achieve this we need a way to check if a string like "author{name,avatar},title,detail" is a valid path in some class. Something like

class User {
    String name;
    String avatar;
    int age;
    // ...
}
class Post {
    User author;
    String title;
    String detail;
    int rating;
    // ...
}

class Request {
    String data;
    @JsonPath(Post.class)
    String fields;
    // ...
}

So, @JsonPath(Post.class) will check if string value is a valid path in Post class.

[cowtowncoder]

I guess I don't yet quite understand how pieces fit together. Would Request POJO then contain another field of type Post.class? Or how would contents of fields tie to something else? And is this for deserialization or serialization?

[cowtowncoder]

Perhaps this could be understood/implemented as sort of alternative filter, combining aspects of @JsonView, @JacksonInject, in which class could be marked to take value passed similar to Attributes (i.e. defined for ObjectReader / ObjectWriter). Although then again there already is @JsonFilter which allows defining named filter for a class, and one of default implementations (include-if-listed) would work.

[raderio]

Would Request POJO then contain another field of type Post.class

No, Request class contains a String, and String value should contain a comma separated values, these values are properties from Post class

And is this for deserialization or serialization?

it is for deserialization, when we receive json from client

[cowtowncoder]

@raderio Ok so where in Request is that Post class? Are Post-valued properties omitted for simplicity? It can not work recursively across all types, there has to be direct reference. So would this apply to any and all Post fields?

[raderio]

In first message you can see

@JsonPath(Post.class)
String fields;

in Request should be a String field with an annotation where is specified the class Post

[cowtowncoder]

Ok no. I don't think this makes sense if I understand it correctly: structure of POJOs should match structure of JSON payload, and it seems to me expectation here is some kind of slicing and dicing of filtering metadata, to result in injection of some values from somewhere else.

If I misunderstand intended logic, what would help here would be actual JSON payload given, and expected contents bound to Request class. Also note that Jackson does not handle possible relationship between incoming (request) and outgoing (response) types; that is what application code or framework would do. Jackson just connects incoming data stream into Java objects of various kinds.