Our REST API

Overview

Costs to Expect is a service focused on tracking and forecasting expenses. We are trying to simplify your budgets. There are three core products in the service; the Open Source REST API, our App and an Open Source website showing the costs to raise our children to adulthood.

Our API is the backbone of the service, everything depends on it. Our API is available to anyone who wants to use it. Our focus is expenses, however, that will change as the product matures.

Access API View our API on Github

The documentation for the API is available as a Postman collection.

Examples Postman

---

Our Products

There are multiple products within the Costs to Expect service, the major products being our API and App, below is a quick overview of each product.

Our API

Our Open Source REST API, available under the MIT license, the API drives the entire service.

Our App

Our App is the commercial offering for Costs to Expect, we are working towards the public alpha, our aim is to make tracking and forecasting expenses as simple as possible.

Our Website

Our website is a long-term social project. My wife and I are tracking all the expenses to raise our child to adulthood.

Our Blog

Our blog acts as a central repository to list all updates, explains why we are doing what we are and acts as a place for us to talk about our products and the service.

---

Latest release v2.17.0

The latest release of the Costs to Expect API is v2.17.0; we released it on the 22nd Nov 2020.

The changelog below shows all the fixes and improvements we have made, to view the entire changelog please check here.

Added

• We have added a `complete` parameter for the `game` item-type; when the parameter is included and set to true, only complete games will be returned in collections and summaries.

Changed

• We have added item-type based response classes for all item collections and summaries. Item and resource type items are unique; there are no shared dependencies. The shared dependencies were a result of the first two item-types being similar, with the addition of the game item-type, we have learnt our lesson.
• We have tweaked the TTL for permitted, and viewable resource types. The TTL for public viewable resource types is higher than for private users.
• With the addition of more item-type classes, we have tweaked our collection TTLs for public and private users.
• We have moved our 'Method' classes; it doesn't make sense for them to sit inside the 'Option' namespace.
• We have moved our 'AllowedValue' classes; it doesn't make sense for them to sit inside the 'Option' namespace.
• We have reorganised all the item-type classes; we are keeping all the classes for each item-type together.
• We have tweaked our response classes; we will do slightly less work when reading from the cache.

Fixed

• We have removed all our interfaces; the interfaces were not useful, and we are going a slightly different way with the item-type classes, interfaces will return.