API Development and Microservices

Interfaces other systems can rely on - properly documented, properly versioned, and not a surprise to consume.

An API is a promise to another system, and often to another company. That makes the design decisions - resource modelling, error semantics, pagination, authentication, versioning - considerably more consequential than they look at the point of writing.

I build APIs that are pleasant to integrate against, and I integrate against other people's APIs when they are not.

Start a conversation

API development and microservices illustration

What I do in this area

Both sides of the interface - building them and consuming them.

REST API design and implementation
GraphQL schema design and resolvers
OpenAPI / Swagger documentation
Authentication - OAuth, API keys, JWT
Third-party API integration

Webhook design and reliable delivery
Rate limiting, quotas and abuse protection
Versioning and deprecation strategy
Microservice decomposition and boundaries
Message queues and asynchronous processing

How an API project runs

Contract first, so consumers can start work before the implementation is finished.

1Consumer analysis

Who is going to call this, and what are they trying to accomplish? An API designed around your internal data model rather than the consumer's task is the most common and most expensive mistake in this area.

2Contract design

The specification is written and agreed before implementation. That lets client teams build against a mock while the backend is being built, and it catches design problems while they are still cheap.

3Implementation

Built with authentication, validation, error handling and rate limiting from the start, not bolted on before launch.

4Documentation and examples

Generated reference documentation plus worked examples. An undocumented API generates support requests forever.

5Versioning and rollout

A clear versioning scheme and deprecation policy, so you can change the API later without breaking every consumer at once.

On microservices, honestly

Microservices solve an organisational problem - letting multiple teams deploy independently - at the cost of substantial operational complexity. If you have one team, they will usually make your life harder rather than easier, and a well-structured monolith is the better engineering decision.

I will tell you that before taking the work. Where a service split genuinely helps, the boundaries need to follow the business domain rather than the technical layers, or you end up with a distributed system that has all the coupling of a monolith and none of the convenience.

Where services do make sense, the parts that matter are the unglamorous ones: idempotency, retry semantics, message queues, observability across service boundaries, and knowing what happens when one service is down. Those get built in, because retrofitting them after a production incident is a bad way to learn. Related: cloud and server administration.

Related services

App Development

Web, mobile and desktop applications for Windows, macOS and Linux, built with a real focus on the end user.

Legacy Code Modernisation

Old codebases made safe to change again: upgrades, refactoring, tests and documentation, without a risky rewrite.

Data Migration & ETL

Moving data between systems without losing rows, breaking references or taking the business offline.

Frequently asked questions

Can you integrate our system with a third-party API?

Yes - payment providers, CRMs, accounting systems, logistics, government services and more. Integration work often includes handling the other side's failures gracefully, which is usually where these projects actually get difficult.

REST or GraphQL?

It depends on your consumers. GraphQL is excellent when clients need varied shapes of data and you control both ends; REST is simpler to cache, document and consume for public or partner APIs. I will recommend based on your situation rather than preference.

Can you document an API we already have?

Yes, and it is often the highest-value small piece of work available. I read the implementation and produce an accurate specification and reference documentation.

Do we need microservices?

Probably not, and I will say so if that is my honest read. The question worth asking first is whether your deployment problem is technical or organisational.