Author: DeanBlackborough

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.

Posted on

API Summary routes

In a previous blog post, I outlined my solution to summary routes, in short, every route in my API will have a matching summary route, the summary route is simply the route with a summary/ prefix.

If the GET endpoint of a route supports parameters the summary route should support the same parameters, in my experience, it will need additional parameters; as always, best shown with an example.

The summary route lives at summary/resource-types/[resource-type]/resources/[resource]/items, the GET endpoint has eight parameters, below I’ll show the expected output for each parameter.

In my API I have the following route /resource-types/[resource-type]/resources/[resource]/items. The GET endpoint returns a collection of the items assigned to the resource; it has four parameters for filtering, year, month, category and subcategory.

No parameters | Total sum of items
years | Summary for each year
year | Summary for the requested year
months | Summary for each month
month | Summary for the requested month
categories | Summary for each category
category | Summary for the requested category
subcategories | Summary for each subcategory
subcategory | Summary for the requested subcategory

So far I’ve not come across any negatives to this structure, yes, there are numerous parameters for the GET endpoint, I don’t consider that an issue, I’d rather have fewer routes than fewer GET parameters.