Ingest Token API

Add an API to get/post ACE Tokens to the Ingest Server.

Base API

For the most part this should be pretty straightforward as these are just some endpoints for query/creating Tokens. All endpoints return a 200 or 401 unless otherwise specified.

• GET /api/tokens
  • Return Page<AceToken>
  • Query Params (filename, bag(?), algorithm)
• GET /api/tokens/<id>
  • Return AceToken
  • Can also return a 404
• GET /api/bag/<id>/tokens
  • Return Page<AceToken> for a Bag
  • Can also return a 404
• POST /api/bag/<id>/tokens
  • Return AceToken
  • Accept batch updates?
  • Does not return a 200
  • Can also return a 201, 403, 404, and 409

We'll also want a few additional classes for converting AceToken Entities into their respective Model

• AceToken model
• AceToken filter
• AceTokenSerializer
• AceTokenDeserializer
• AceTokenSearchCriteria
  • id
  • bag_id
  • filename
  • algorithm

Batch Operations

We might want to include some batch operation utilities as well for creating and querying AceTokens.

Creation is fairly straightforward - just update the model used when POSTing, and return the results for each token ('Created|Fail + Reason'). We could possibly read an InputStream as well but I'm not certain how well that would work. Either way the clients will need to be updated with some logic for how to push tokens and handle errors.

Query is a bit more complex, with more questions surrounding what we want to take in and return. We could just take a List[Filename] and create queries for tokens based on that. This brings a question of if we should create an index on (bag_id, filename), which seems like it would likely be the case. I'm not sure what type of performance this would have, what the queries would end up looking like, and even what we respond with ("exists":true??).

Both of these can be worked on after we have the Base API in place, after which we can start testing to see how exactly these can be implemented. Maybe it can be broken off into a new issue once afterwards as well.