Gateway Gus saysEvolve an API by adding, not breaking — additive changes keep old clients working.
You can add new optional fields, new endpoints, and new optional parameters without breaking anyone — clients ignore what they don't know. Breaking changes (removing/renaming fields, changing types, tightening validation) require a new version. Design responses to be tolerant readers and treat the contract as a promise. Most evolution should be additive.
Power-ups you unlock
Additive changes are safe (new optional fields)
Breaking changes need a new version
Clients should ignore unknown fields
Treat the contract as a promise
Timeout Titan attacks — common mistakes
Removing/renaming fields in place
Tightening validation on a live version
Changing a field’s type silently
Boss battleClassify each as safe or breaking: add a field, rename a field, add an endpoint.
Example code
<!doctype html><html><head><meta charset="utf-8"></head>
<body style="background:#06040d;color:#e6e0ff;font-family:monospace;padding:20px"><pre>add optional field → safe
add new endpoint → safe
rename/remove field → BREAKING → new version</pre></body></html>