As an online business grows in popularity it can highlight scalability problems in your architecture. Certain hardware and/or software components can struggle to keep up with increased demand and it may not be easy or cost-effective to address this by extending them in their present form, especially when the demand is ‘spiky’ in nature. My team was recently faced with such an issue. We decided to engineer our way out of the problem by designing a more scalable replacement solution. Key technical requirements for the new solution included the throughput and latency of a public web API. In this post I share details of how you can measure these performance characteristics of an API using Apache JMeter, and in the process I identify a very useful supporting JMeter plugin.
My team and I design and build a lot of REST APIs during the course of our work, to expose functionality and data to client systems, and to integrate our back-end services with one another. I was therefore interested in learning more about Amazon’s recently launched API Gateway service. This is a short post summarising the role and major features of Amazon API Gateway based on my own preliminary research and trialling. I also briefly cover what the service is not designed to support, and consider possible future use-cases.
I’ve recently designed and built an open source API client for the REST API of a major enterprise video and webcast service, for use by its customers. It was a rewarding exercise that has helped me gain some valuable additional practical experience of emerging technology and tools for building and testing apps. This post outlines the value of the API client, its design, the technologies and tools I used, and how I rate them. I’ve open sourced the code to allow customers, and others, to view and reuse what I’ve built.
This is the next in a series of posts on RESTful web API design based on my experience of designing and building a set of public RESTful web services for a popular online platform. This post highlights the importance of upfront design of a separate model for REST resources, and contains suggestions on how to implement such a resource model in an API service’s application architecture.
When I was recently tasked with designing and building a new set of public-facing REST APIs for a popular online platform, one of the design challenges I faced was whether we should version our web APIs, and if so, how?
Historically there has been a lack of consensus in the industry on best practice in this area of web API design. And on initially researching the problem area I couldn’t find the answers I was looking for, or advice that I felt I could rely on.
This post distills the things I learned from further research and the experience of designing our own web APIs, with the aim of helping those of you that need to tackle a similar design problem. It covers:
- Reasons to consider versioning your web APIs.
- The aspects of a RESTful web API which do and don’t require versioning.
- A classification of the most popular API versioning solutions that are in use today, including which aspect(s) of a RESTful web API they aim to version;
- Points to consider when choosing a versioning solution(s).
It concludes by explaining my current thinking on the best approach to versioning and what solution we adopted for our APIs. I hope you find it useful!