Release Multiple item types · costs-to-expect/api

[v2.04.0] - 2019-11-11

We have added a GitHub callout to the top right corner of the API landing page, courtesy of https://github.com/tholman/github-corners.

We have updated the code to ensure the data arrays in the config files get used whenever possible; minor data arrays for parameters defined in two locations.
We have added additional summary models.
We have moved the item and resource type item models, now organised by namespace, not the class filename.
We have moved the item and resource type item transformers, now organised by namespace, not the class filename.
We have moved all the existsToUser methods out of the item models and into a PermittedUser model.
We have updated the item and resource type item summary routes; they respect the chosen resource type (Allocated expenses and Simple expenses) and provide the relevant summary.

We have added a new route, item-types, the route shows the item types supported by the API.

We have updated the landing page; the focus was previously on the website; the API is the backbone of the entire service; the site is ancillary.
We have moved the summary controllers; we should use namespaces to organise the code, not filenames.
We have moved the summary transformers; we should use namespaces to organise the code, not filenames.
We have started to move the summary models; we should use namespaces to organise the code, not filenames.
We have merged the authorised and general API routes section, the README details the API routes and the API summary routes in two tables.
We have moved some configuration files. We thought it was odd how some were outside of folders; additionally, config files should only be in folders if there can be multiple files for the 'section'.
We have moved localisation files to match their config partners.
We have updated the allowed values for the year GET parameter; we derive the values from the data; the limit for Jack should be 2013 to 2019, for Niall te limit should be 2019.
We have updated the GET parameter validator; supplied values validated against values defined in the OPTIONS request.

We have corrected the category summary routes in the README.
We have corrected the name of a few transformers, incorrect capitalisation.
We have corrected the name of a few controllers, incorrect capitalisation.
We have set the salt for the item type hasher.
For uncaught exceptions, we return the trace when the API is in development mode.
We have updated the code to generate conditional GET parameters; the item type defines which parameters exist.