Last post I made I covered the recreate deployment strategy and, since I’m trying to review as many deployment strategies as possible, this post will cover another type of deployment: the canary deployment. Other posts in this series Recreate/in-place deployment Blue/green deployment Canary deployment A bit of history In my previous post, the names of the deployment strategies were pretty self-explanatory, and this one also is if we understand where it’s name comes from.

There are several ways to deliver, or deploy, software and making it available to users. While there are folks out there specialized in managing these and many software engineers focus only on the business logic side of life, it is still important to understand how the deployment process works and how it may affect users. In this post, I’ll cover one of the simplest deployment strategies, the recreate deployment strategy.

The main way developers interface with a given API is through an endpoint, which is simply a URL that developers can perform HTTP requests against. But what HTTP requests can be performed? And what information must the developers send to the server and what information do they get back? These are all important considerations that must be taken into account when developing a REST API. Other posts in this series REST APIs, their types, and their value chain REST architecture constraints Designing REST APIs Example of a REST API's endpoint Some of these elements are fairly obvious: the base domain is how users know they are interacting with your organization, but the product part usually requires a bit more thought.

Possibly one of the main benefits of REST is the architectural style that it defines via what are known as the REST architecture constraints. These guiding principles allow software designers to have a common ground for beginning their API design whose advantages and disadvantages are already known, tried, and tested. There are six of these constraints: Client-server Uniform interface Statelessness Caching Layered Code on demand One important note before we review these is that these aren’t a hard constraint on how you should build your software.

First things first, an Application Programming Interface (API) is a user interface to data and systems that is consumed by applications rather than humans. Think of it as an interface through which computers, programs, frameworks can interact with each other via a well defined contact between the consumer and the API provider. An adjacent concept is that of remote procedure calls (RPCs), which can be used by clients (analog of consumers) to invoke procedures or functions from a remote server (analog of API provider) as if it were a local function.

I’ve been meaning to do this for a while now. I’ve studied quite a bit of Kubernetes in the past year and have a ton of handwritten notes that I want to throw away, so I’m transfering all of those notes into my blog. This is also a great review opportunity (and also has the added advantage that I will stop needing to comb through endless sheets of paper when I want to remember something).