API – v2.24.0 & Progress Update

This release continues to clean up the API and correct some of the design issues introduced during the addition of new item types. Forecasting and budgeting will be making their way to the API soon, it makes sense to simplify some of the unnecessary abstractions that crept in. The forecasting and budgeting system will not behave in the same way as traditional expenses so it doesn’t make sense to try and adapt the system I had, rather allow there to be differences between all the item types.

There are 11 development stories (more will be created) and the rest of the tests to write, the API will then be ready to ship, well, the soft release will be ready. The API is not officially ready until the documentation has been moved away from Postman and budgeting forecasting support exists, either way it will be a massive milestone for us.

After that, I move towards getting the App to the same stage, soft release. When the App and API are at the same milestone, development begins on forecasting and budgeting, there might be a small intermission whilst I build another app but that can be thought of a proof of concept for the budgeting.

The next four months are going to be full-on, all we can do is see where we are in September and go from there.

Added

• We have added our first schema files for OPTIONS responses and started working on the tests.
• We have added tests for category management, found one bug when creating the tests.

Changed

• We have updated our response class for OPTIONS responses, we now allow parameters to be defined for POST requests. One example of where we need this is the create password POST request, password and password_confirmation are required fields, however, token and email are required parameters. Before this update, you had to parse the returned error of read the OPTIONS request description.
• We have started splitting config files, a config file should be for one purpose.
• We have spent quite a bit of time reviewing the API structure and refactoring. We have removed unnecessary complexity, renamed classes and methods to describe intent more clearly and removed pointless base classes.
• We have reworked how allowed values are generated for the different item types, allowed values for fields and parameters have been split, and we have removed all abstraction.
• We have removed some route validation files which didn’t do anything useful after all the item type work.
• We have reworked the responses class, removed exception parameters when not necessary, pass in an exception if thrown and now delegated responsibility to the responses class to decide if the exception should be returned in the response.
• We have upgraded the API to Laravel 9 and PHP 8.1.

Fixed

• Options request incorrect for the auth.register endpoint (Test added).
• Options requests returning response twice.
• Type corrected in OPTIONS response, authentication status/requirements now a boolean, not a string.
• Minor correction to the description of two POST endpoints.
• Corrected a type in the OPTIONS response for the month parameter.
• Corrected the partial-transfer JSON schema file.
• Allowed values not showing for category on GET endpoints.
• Inconsistent usage of the responses helper.
• Category validator allowed duplicate names due to incorrect params, caught by model.

Removed

• We have removed the ItemType base class and all the child classes.
• We have removed a redundant validation class and moved the response method into the main response class.