Do not change URIs, oops

A core rule of the Internet, don’t change a URI. I’m going to change some, why, we all make mistakes.

I released the initial version of the Costs to Expect API during the summer of ’18. It turns out when you review your code/API after a short break you spot all the issues you were oblivious to during development.

Over the next 12 months, I’m going to extend the Costs to Expect API, an API that I intend on maintaining for a significant period; I need to record data for at least the next 13 years.

If there were one small issue with the URIs, I’d deal with it, change a couple of URIs and add redirects. There are numerous issues; I am not happy with the initial summary routes. I favour dashes in the URIs over underscores, some of the words are incorrect and other minor issues.

We haven’t pushed the service; it doesn’t exist. As far as I am aware I am the only consumer of the API. I believe it is OK to modify the URIs, as long as I do not modify them again they should remain the same for twenty times longer then they have existed.

Costs to Expect API

The Costs to Expect API is ready for release*.

I’m going to continue development to add additional features and start working on the summary endpoints and endpoints required for the companion website, however, the API itself could be released today.

The API is ready, five years and two months of child costs exist, the two need to be put together.

I’m going to work with my Wife to review and categorise the data. Our data is categorised, however, for the API we want to break the data down a little more, our data is split into thirteen categories, we intend to have fewer base categories and subcategories to provide the detail.

*I’m not setting a release date, it will be soon though, I want to get the API out before I look for a new contract and go back to work.

Once the API is out, I will start development on the companion website for data input (preview for iOS app), the iOS app and the website to display the data.

We have several long-term plans for the Costs to Expect API and website, one being to allow additional data, for example, localised costs for childcare/hobbies etc. Our intention is you will be able to augment our base data to get a more accurate idea.