Pagination of items in Rest API

[kstamatis]

Hello group members,

Regarding pagination of items in Rest API, I mentioned the following in the current code hosted in github master:

In the "collections/" endpoint, there are "limit" and "offset" request params that are used in pagination of collections (https://github.com/DSpace/DSpace/blob/master/dspace-rest/src/main/java/org/dspace/rest/CollectionsResource.java#L97).

However, the same params are passed in the creation of the collection object (https://github.com/DSpace/DSpace/blob/master/dspace-rest/src/main/java/org/dspace/rest/CollectionsResource.java#L105) which is wrong since the latter are used in the item pagination as well. In the same line, the "null" param means that expand is not considered in this endpoint.

In the collections/{id} endpoint however, limit and offset request params are correctly used for the pagination of items.

So, there is a misleading usage of limit and offset params. In one case, they are used for collections pagination and in the second, for item pagination.

My guess is that "collection/" endpoint should give the option to expand items (and thus, offset and limit only refer to collections) while the "collection/{id}" endpoint can expand items using the offset and limit from the request.

I also think that items/{collection_id} endpoint is missing. It is useful for getting all the items of a specific location (it can be done via "collection/{id}" endpoint but it is more straightforward to ask items of a specific collection.

Another point I would like to discuss is the option to provide some subset of metadata of the items in the "collections/..." endpoints. Currently, if someone requests for a collection with "item" expanding, it gets the items but the "metadata" of the items is not expanding. So, if someone wants to display some sort of information of items (ie a list of items), he only has the name of the "item" which is the title. Is he wants to display the authors as well (before showing a full detail page of the item), he needs to ask for the specific item to get the metadata. So, we may preconfigure some metadata (maybe via the cfg file) to be displayed in the item endpoint without needing of expansion.

Regards,

Kostas Stamatis

[Peter Dietz]

Hi Kostas,

Take a look at Anja's in-progress work on context, and other limit/offset improvements. https://github.com/peterdietz/DSpace/pull/2

My thoughts on the difference between who gets affected when you change the limit/offset, is that if you have the collections-list, you need to page through the collections-list. When you have a Single Collection, you can't page through that collection, but you can page through its items. Also, I stopped the ?expand=all from recursively following all sub-resources, to prevent some type of infinite loop. To support partial responses, maybe something like /collections/{collectionID}?fields=dc.title,dc.contributor.*,dc.date.*, or however this is commonly notated.

I don't like an endpoint like: /items/{collectionID}, those items belong to the collection. And I don't want to deal with the ambiguity of /endpoint/<Integer>, does that Integer map to a CollectionID, CommunityID, ItemID, ...

Maybe you could add some sugar to the endpoint, like /collections/{collectionID}/items, to get only the array of Items, minus the specified collection's information.

I could be okay with advanced search filters though, such as /items/search?collectionID={collectionID}

I'm basing the design around the Apigee guide's best practices: http://info.apigee.com/Portals/62317/docs/web%20api.pdf

Peter Dietz

--
You received this message because you are subscribed to the Google Groups "DSpace REST" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-rest...@googlegroups.com.
Visit this group at http://groups.google.com/group/dspace-rest.
For more options, visit https://groups.google.com/groups/opt_out.

[kstamatis]

I agree, "items/{collection_id}" is not good. Your solutions are more correct.

Regarding the "limit" and "offset" I have to study Anja's work.

However, stoping the expand=all from the "collections/" endpoint is problematic. It is supported in the "collections/{id}" endpoint but not on "collections/" endpoint. Either way, documentation on DSpace wiki must be updated accordingly since it says that expand is supported on "collections/" endpoint as well. Maybe, the expand=items should be dropped.

Regards,

Kostas