Item List

[Anja Le Blanc]

I've added some code to produce an items list. To avoid running out of memory I added a new config setting (max_pagination) for rest config with which the administrator can define the upper limit.
I also created a new type for that return, so that it can carry some metadata about the original query. At least the data should now not be completely out of context.

<itemList>
  <context>
    <limit>15</limit>
    <offset>10</offset>
    <query>http://130.88.120.147:8080/rest/items?limit=15&expand=parentCollection&offset=10</query>
  </context>
  <item><expand>metadata</expand><expand>parentCollectionList</expand><expand>parentCommunityList</expand><expand>bitstreams</expand><expand>all</expand><handle>10949/9895</handle><ID>10733</ID><name>Surform Block Plane</name><type>item</type><archived>true</archived><lastModified>2013-03-11 11:13:33.994</lastModified><parentCollection><expand>parentCommunityList</expand><expand>parentCommunity</expand><expand>items</expand><expand>license</expand><expand>all</expand><handle>10949/29</handle><ID>27</ID><name>HE - Creative Arts and Design</name><type>collection</type><numberItems>4391</numberItems></parentCollection><withdrawn>false</withdrawn>
  </item>
  <item>...

Do you have any objections to this kind of method? Could it cause problems? If not I could apply the same principle to the other 'listings', e.g. communities, collections.

Originally we said we would work against Peter's repository (https://github.com/peterdietz/DSpace/tree/rest-jersey). But when I try to initiate a pull request against it, it is somewhat behind 'master' so that my PR carries a good number of other commits not just the ones my branch is ahead. I don't want to mess things up. Peter, how would you like to receive code?

Best regards,
Anja

[Peter Dietz]

I agree that there should be some type of max-limit, so that a bad client can't set a limit=1000000 and crash the system. In that case, I think your options are either to send 400 Bad Request that limit is out of range, or 200 and correct the request by reducing the actual limit to max-limit. If we had a proper input validation system for REST, then it might make sense to have some type of filter through the 400 for us.

I had intended for /items/ to be page-able, it might not have too much meaning if you don't have any type of search powers to order or filter the results, but we can still allow for iteration. I think we want /items list, /collections/:id/ item-list, and /communities/:id/ item-list, as well as search at each place. 

I do like having a response-metadata, but I didn't want to conflict with item-metadata (dc.title, ...), or potentially metadata-for-all, so if you've got an idea on how-not to clash go for it. I chatted with my local metadata librarian, and she said descriptive-metadata is probably where dc.title goes, structural-metadata is the relationship of the objects to each other and their order (this is usually METS, so I'm not interested in pursuing that). In our case, I think request-metadata would be the best I can come up with, for the thing that tells you the: offset, limit, totalItems, order, search, ...

I don't want to be a bottleneck, so you can feel free to work on your own branch against DSpace/DSpace:master. We can all PR each other, and then send another PR upstream to DSpace/DSpace.

Yeah, my master is a bit-out-of-date, but GitHub doesn't seem to have a problem taking PR's from new branches.

I wonder if we would want to make a feature branch on DSpace/DSpace called feature-rest-search or something

[Ivan Masar]

On Tue, Oct 29, 2013 at 7:46 PM, Peter Dietz <pdie...@gmail.com> wrote:
> I wonder if we would want to make a feature branch on DSpace/DSpace called
> feature-rest-search or something

This is cool for collaboration between commiters, where it avoids
unnecessary PRs. But in case of you (a commiter) and Anja (a
non-commiter) collaborating, this has no added benefit compared to
just hosting the branch in your fork as usual (because Anja would have
to do PRs in either case and you can commit directly in either case).


Regards,
~~helix84