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.
Added
- 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.
Changed
- We have added item
name
anddescription
fields to the partial-transfers collection. - We have updated the schema for partial-transfers.
- We have updated the game item-type; the
winner
field will now be null or an object, the object will have anid
and aname
. - We have updated the OPTIONS request for the
game
item-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-expense
item 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
resources
at 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.
Fixed
- We have corrected several configuration file calls; our calls were looking at transfers, not partial transfers.
- We have added localisation files for the
simple-item
andgame
item-type, several were missing.