Category: Costs to Expect

Posted on

API endpoints, filtering, sorting, searching, limiting and summarising

The Costs to Expect API is developing slowly; features get added as I need them, v1.15.0 is an exciting release, it will be the first time an endpoint in the API can be filtered, sorted, limited, searched and summarised.

I’ve written previously about summarising collections, with the release of search in v1.15.0 it makes send to describe all options supported by the items (/v1/resource-types/[resource-type]/resources/[resource]/items) collection on the Costs to Expect API.

By default, the items collection returns all child expenses in reverse chronological order, ‘all’ and ‘reverse chronological’ are sensible defaults; however, the API is limited if the collection always returns everything, you need to be able to filter, sort, limit, search and summarise.

The Costs to Expect API supports filtering, sorting, limiting and searching via parameters appended to the URI, collections are summarised by prepending /summary/ to the URI. Summary endpoints support the same filtering and searching options as their companion collections, limiting and sorting don’t make any sense in the context of a summary.

A URI can quickly become unreadable when multiple GET parameters are assigned, to attempt and improve readability I have grouped sorting and searching.

The OPTIONS requests for the Costs to Expect API detail all the supported GET parameters, in addition to giving an overview of each parameter, the OPTIONS requests list which fields and sortable and searchable. The sort and search parameters both allow multiple conditions.

Limiting a collection is handled as expected, there is an offset parameter to define the start record and a limit parameter to define the number of records requested.

Filtering a collection is handled via individual parameters, filtering is more common than searching and in my opinion needs to be the most verbose, when reviewing a URI the filtering parameters should be more visible.

This solution won’t work for everyone; however, if you need to support filtering, searching, sorting, limiting and summarising, I think it provides an excellent level or readability while still being practical.

Posted on

Year off

Eight weeks ago I concluded my 16th contract, yes, I have been contracting for a while, over ten years so far.

I enjoy contracting; I continually meet new people; additionally, by moving around, I have been fortunate enough to be exposed to numerous business domains, frameworks and tools.

We can’t ignore the elephant in the room, contracting pays well, especially when you have over 20 years of experience.

In April, my Wife had our second child, Niall. When we had our first child, we realised that the best way to provide the support my Wife needed was to take time off, there were so many positives with me providing the support rather than getting in professional help. Well, with Niall, we are going to do the same thing, I’m going to take at least a year off, primarily to help my Wife raise our brand-new son, secondly, to try and get the Costs to Expect service off the ground.

Costs to Expect is a project I had been considering for a while, during the summer I released the first version of the API; I plan to develop the MVP of the service during my time off.

Twelve months is not as long as you think, especially when you are a single developer. I’ve used Pivotal Tracker for years; it has become scarily accurate at predicting what I will be able to accomplish during a two-week sprint. I usually have two or three sprints worth of work in my backlog, according to Pivotal, it is going to be quite difficult to get enough of the service ready in 12 months, hopefully, if I plan well, I should be able to do it.