Pagination of primary data not supported

[jasminb]

Pagination of primary data not supported

[jasminb]

@emetsger will take the code you written to handle links and incorporate it into the proposal from @bradtofel.

[emetsger]

Here are a couple of proposals to handle this. What do you think?

Supply a List factory to ResourceConverter

The ResourceConverter uses a factory interface for producing the List instances that are returned by readObjectCollection. The factory interface provides access to the top-level links and meta so the caller can return a custom List implementation. If the caller doesn't supply an implementation, the default implementation is used by ResourceConverter and returns an ArrayList.

Update ResourceConverter to expose pagination state

Because pagination is a part of the JSON API specification, it would be reasonable to have readObjectCollection expose pagination state. readObjectCollection could be updated to return a PaginatedList:

<T> PaginatedList<T> readObjectCollection(...)

    public class PaginatedList<E> extends AbstractList {

        private String prev;

        private String next;

        private String first;

        private String last;

        private List<E> objects;

        public String getPrev() {
            return prev;
        }

        public void setPrev(String prev) {
            this.prev = prev;
        }

        public String getNext() {
            return next;
        }

        public void setNext(String next) {
            this.next = next;
        }

        public String getFirst() {
            return first;
        }

        public void setFirst(String first) {
            this.first = first;
        }

        public String getLast() {
            return last;
        }

        public void setLast(String last) {
            this.last = last;
        }

        public List<E> getObjects() {
            return objects;
        }

        public void setObjects(List<E> objects) {
            this.objects = objects;
        }

        @Override
        public E get(int index) {
            return objects.get(index);
        }

        @Override
        public int size() {
            return objects.size();
        }

    }

[jasminb]

Hey, similar problem is also present with meta, where it is not possible to expose it without having some kind of collection wrapper.

So, instead of having PaginatedList, something like ResourceCollection class could be implemented that would allow exposing both pagination and meta objects.

[emetsger]

Ok, thanks, I'll take a look at it!

[sailorseashell]

Any updates on pagination support? Currently this is the most complete implementation of jsonapi.org's spec on Java and I'd like to use it but I can't without pagination support.

[jasminb]

Should be on develop in next few days.

[emetsger]

@jasminb

Any thoughts on my ResourceList implementation? It may not be the best
name. I avoided the name ResourceCollection because I didn't want to
conflate the Java concept of Collection with the JSON-API concept of
collection (and besides, the method returns a List anyway).

On Fri, May 20, 2016 at 12:11 PM, Jasmin Begic [email protected]
wrote:

Should be on develop in next few days.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#33 (comment)

[bradtofel]

I think the PaginatedList(/ResourceList) solution will cover some cases, but I'm not sure if it handles everything.

According to the spec, it's possible to have a 'links' field for each Resource.

So we could have:

A:
{
'links' :{},
'data' :{}
}

B:
{
'data' :{'links':{}}
}

C:
{
'data' :[{'links':{}}]
}

In the above scenario, you can also replace 'links' with 'meta'. (Maybe we leave the 'meta' on 'links' out of scope for now?)

Currently in master, (I think) only 'A' is handled for Resource request, by placing the 'meta' data onto the returned Resource (via annotation.) This has major simplicity advantages. PaginatedList would also handle 'A', but I don't think scenarios 'B' or 'C' are handled.

Using @links and @meta annotations on Resource POJOs seems very natural and simple, and to me feels like a very good fit for scenarios 'B' and 'C', where the 'links' (or 'meta') data applies to the Resource.

I'm wondering if it makes sense to add a top-level response object, call it maybe JSONAPIResponse, or JSONAPIDocument, which is always the target container for meta/links at the top level (scenario 'A') as well as for the 'data' field, for both Resource and collection responses. It would also be a natural place to put 'errors', 'jsonapi' down the road.

It seems like we could support current interface to ResourceConverter, for those who don't need the extra layer:

    public <T> JsonApiDocument<List<T>> readCollectionDocument(byte[] bytes, Class<T> clazz) {
    // magic happens...
    }

    public <T> List<T> readObjectCollection(byte[] bytes, Class<T> clazz) {

        return readCollectionDocument(bytes, clazz).getData();
    }

[emetsger]

@bradtofel I agree that a higher-level abstraction is needed, and I like the idea of the JsonApiDocument. It would maintain binary compatibility and offer a path forward for the optional members in the response (like jsonapi, etc.).

[bradtofel]

hey @jasminb was just getting that PR together. : )

Feel free to grab any bits from there that look like they'd fit as well.

[jasminb]

@bradtofel will do, thanks!

Im having some doubts about @Links annotation on resource classes. Meta, for instance, is something that API designer decides on how it will look like and consumer can create POJO and annotate accordingly. As for links, those are static so basically besides saying something is a link you are forced to use appropriate type to with the annotation which makes is kinda awkward.

[jasminb]

@emetsger @bradtofel Please see #41

This is just a placeholder PR for ongoing work that will be performed on the given branch.

Currently working (not unit-tested):

• top level and resource level meta
• top level links

Resource level links is still work in progress.

[bradtofel]

@jasminb I'm not sure I follow what you mean about static? Do you mean to deal with the 'links' from scenario 'B' or 'C', you'd have to have a member of a type from this library to deal with it, like below?

class Bar {
  @Links
  com.github.jasminb.jsonapi.LinksData barLinks;
  ...
}

[emetsger]

@jasminb Yes, I'm with @bradtofel regarding @Links:

{
    "data": [
        {            
            "links": {
                "info": "http://localhost:8000/v2/files/57347c2ecfa27c00468cedc3/",
                "self": "http://localhost:8000/v2/files/57347c2ecfa27c00468cedc3/",
                "move": "http://localhost:7777/v1/resources/pd24n/providers/osfstorage/57347c2ecfa27c00468cedc3",
                "upload": "http://localhost:7777/v1/resources/pd24n/providers/osfstorage/57347c2ecfa27c00468cedc3",
                "download": "http://localhost:7777/v1/resources/pd24n/providers/osfstorage/57347c2ecfa27c00468cedc3",
                "delete": "http://localhost:7777/v1/resources/pd24n/providers/osfstorage/57347c2ecfa27c00468cedc3"
            },
            "attributes": {
                "extra": {
                    "hashes": {
                        "sha256": "39e810498a96517091cac7f59abb3a57d115f3c8b8b1e22648426dfe66bf9cd7",
                        "md5": "19d61973a43bf1550aef3241b5543076"
                    }
                },
                "kind": "file",
                "name": "porsche.jpg",
                "last_touched": null,
                "materialized_path": "/porsche.jpg",
                "date_modified": "2016-05-12T12:50:54.488Z",
                "date_created": "2016-05-12T12:50:54.488Z",
                "provider": "osfstorage",
                "path": "/57347c2ecfa27c00468cedc3",
                "checkout": null,
                "size": 16064286
            },
            "type": "files",
            "id": "57347c2ecfa27c00468cedc3"
        }
    ],
    "links": {
        "first": null,
        "last": null,
        "prev": null,
        "next": null
    }
}

The resource in the data member above models a domain entity File. The data.links member contains URLs used to manipulate the file. So in my Java class for the domain entity, I might have a member like:

@Links
Map<String, ?>

Essentially the same as @Meta. As an API designer, I may use @Links just as I would use @Meta. The reasoning used to support an @Meta annotation is the same reasoning you would use to argue for an @Links annotation.

[emetsger]

See this in my link-annotation branch: @Links can be used to map to a domain object or to a Map<String, ?>.

Better yet, the LinksTest unit test.

[jasminb]

Hey @emetsger, I've merged #41. Please check it out and close the issue.