Lesson 1.3

Content negotiation and versioning

Removing a field, renaming one, tightening validation, or changing a status code are all breaking.

4mBeginner19.4k students

Overview

Plan for the second version before shipping the first

Removing a field, renaming one, tightening validation, or changing a status code are all breaking. Adding an optional field is not — provided clients ignore unknown fields, which you should state explicitly.

A version in the path is the most obvious and most widely understood option. Header-based versioning is tidier and harder for people to use with a browser or a curl command.

Whatever you choose, publish a deprecation policy and honour it. An API that changes without notice is one people build defensive wrappers around.

In this lesson you will:

  • Decide what counts as a breaking change
  • Pick a versioning strategy and hold to it
  • Deprecate on a published timeline

Resources

Previous Lesson
Next Lesson
Content negotiation and versioning — API Design with Node.js — Vertex