In this release, we continue our long-term task of ensuring the API can handle all the different item-types we have planned. The initial version of the API focused on expenses; slowly, we are adjusting the API to a more modular system.
- We are now locally caching the permitted and viewable resource types; this change means we can skip a more expensive query per API request whilst the response is cached, we are experimenting with the TTL.
- We have added item
descriptionfields to the partial-transfers collection.
- We have updated the schema for partial-transfers.
- We have updated the game item-type; the
winnerfield will now be null or an object, the object will have an
- We have updated the OPTIONS request for the
gameitem-type; the allowed values for the winner field will display if necessary.
- We have tweaked our middleware; we use our Hash class rather than duplicating the effort.
- We have created several new classes to generate the allowed values data; these new classes are specific to each of our supported item-type. This change will speed up the OPTIONS requests for the non
allocated-expenseitem type as we will no longer query the database when we know there will be no results.
- We have added a check to limit access to the partial-transfers route. The ‘allocated-expense’ item-type supports the partial-transfers feature, partial-transfers don’t make sense for the other item-types.
- We have drastically simplified route validation. The API controls access to
resourcesat the resource type level; we have updated all route checks to validate the requested resource type rather than validate specific access to the request entity.
- We have corrected several configuration file calls; our calls were looking at transfers, not partial transfers.
- We have added localisation files for the
gameitem-type, several were missing.