Costs to Expect is a service originally intended to track and forecast expenses. This API is the backbone of the service and is not limited to tracking expenses, over the years we have made it flexible enough to record almost anything, including dice games.

The documentation for the Costs to Expect API can be found at GitHub. It may not been 100% complete, our old documentation is available on Postman at postman.costs-to-expect.com.

The API is used by the following Apps;

• Budget Our free and Open Source Budgeting tool
• Budget Pro The commercial version of Budget
• Expense Our free and Open Source expense tracker
• Yahtzee Game Scorer Our Yahtzee Game Scorer, free for all to use
• Yatzy Game Scorer Our Yatzy Game Scorer, free for all to use
• Social Experiment How much does it cost to raise a child to adulthood in the UK?

I'm going to assume you are using Docker, if not, sorry. You should be able to work out what you need to do for your development setup from the steps below.

Go to the project root directory and run the below.

• $ docker network create costs.network *
• $ docker compose build
• $ docker compose up -d

We include a network for local development purposes, I need a local copy of the API to communicate with my local App. You probably don't need this so remove the network section from the docker compose file and don't create the network.

You now have a working environment, so need to set up the API. There are two Docker services, api and mysql, we will need to exec into the api service to set up our app.

Firstly, we need to check we are trying to access the right location, execute docker compose exec costs.api.app ls. You should see a list of the files and directories at the project root.

Next, we need to configure the API by setting out local .ENV file our .env, installing all dependencies and running our migrations.

• Copy the .env.example file and name the copy .env. Set all the empty values, all drivers have been set to our defaults, sessions, cache, and the queue default to the database driver.
• docker compose exec costs.api.app php artisan key:generate
• docker compose exec costs.api.app php artisan migrate)
• docker compose exec costs.api.app php artisan queue:work
• Run an OPTIONS request on http://[your.domail.local:8080]/v3/resource_types, you will see an OPTIONS response, alternatively a GET request to http://[your.domail.local:8080]/v1 will show all the defined routes.
• You can create a user by POSTing to http://[your.domail.local:8080]/v3/auth/register.
• You create a password by POSTing a password and password_confirmation to the URI register response.
• You can sign-in by posting to http://[your.domail.local:8080]/v3/auth/login - you will need a bearer for all the routes that require authentication.
• Our API defaults to Mailgun, populate MAILGUN_DOMAIN and MAILGUN_SECRET with the relevant values from your account, you will also need to set MAIL_FROM_ADDRESS and MAIL_TO_ADDRESS. You may need to set Authorized Recipients in Mailgun.

• On success, collections will return an array and a 200.
• On success, show requests will return a single object and a 200, no response envelope.
• Successful POST requests will return a single object and a 201, there are minor exceptions where we return a 204.
• Successful PATCH requests will return 204.
• Successful DELETE requests will return a 204.
• Non 2xx results will return an object with a message field and optionally a fields array. When we return a validation error, the response will be 422 and include a fields array which will contain all validation errors.

The API caches responses per authenticated user and there is a public cache.

You can skip reading from the cache for a specific request by adding the X-Skip-Cache header, any value will do, the existence of the header is all that matters.

Cache is cleared when we detect a change to relevant data.

Responses will include multiple headers, the table below details the intention behind each of our custom headers.

Access to a route is limited based upon a users permitted resource types. When a user creates a resource type they have full access to everything below it, additionally, the same is true if you are assigned as a permitted user to a resource type.

Public resources types provide READ access to everyone, WRITE access is limited to the permitted users.

You can exclude public resource types by include exclude-public=true in the query string.

Eventually, there will be a summary route for every API collection GET endpoint. Until that point, the summary routes that exists are detailed below. Some allow GET parameters to break down the data, one example being v3/summary/resource-types/{resource_type_id}/items.

Review the OPTIONS request for each summary route to see the supported parameters, these should largely match the non-summary route.

We are in the process of moving our feature tests from Postman, we are moving them locally and using PHPUnit.

You can see our progress in the table below. We are hoping to add tests in each new release. We are not too concerned about missing anything as we still have all our tests in Postman, we won't disable our test monitor until our local test suite is as complete as the Postman request test suite.

*Non yet does not mean there are no tests, it just means there are no PHPUnit tests. There are over 2000 tests in a private Postman collection, I'm slowing transferring them locally and expanding the test suite.