Versionado de API y compatibilidad con versiones anteriores
Aprenda estrategias para evolucionar las API sin romper los clientes existentes, incluidos los esquemas de versionado y las reglas de compatibilidad.
Versionado de API y compatibilidad con versiones anteriores es una lección gratuita de System Design Basics for Backend Developers en CoddyKit. Esta es la lección 4 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de System Design Basics for Backend Developers, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de System Design Basics for Backend Developers incluye 4 lecciones en total.
Partes de esta lección aún no han sido traducidas y se muestran en inglés.
Why APIs Must Evolve Carefully
Once an API has clients, you cannot freely change it. Renaming a field or removing an endpoint can break every consumer. Versioning lets you evolve the API while existing clients keep working.
Breaking vs Non-Breaking Changes
Know the difference:
- Non-breaking: adding a new optional field, adding a new endpoint
- Breaking: removing a field, renaming a field, changing a type, making an optional field required
Non-breaking changes can ship without a new version; breaking ones cannot.
URI Versioning
The most visible scheme puts the version in the path. It is simple and cache-friendly, and clients can clearly see which version they call.
GET /v1/users/42
GET /v2/users/42Header Versioning
Alternatively, clients request a version via a header. This keeps URIs clean and treats the version as part of content negotiation.
GET /users/42
Accept: application/vnd.myapp.v2+jsonQuery Parameter Versioning
A lighter approach uses a query parameter, e.g. ?version=2. It is easy to test in a browser but mixes versioning with regular parameters and can complicate caching.
GET /users/42?version=2Semantic Versioning
SemVer (MAJOR.MINOR.PATCH) communicates intent:
- MAJOR: breaking changes
- MINOR: new backward-compatible features
- PATCH: backward-compatible fixes
For public HTTP APIs, the MAJOR number usually maps to the URI version.
Additive Change Discipline
The cheapest versioning is not needing a new version. Follow the additive rule: only add, never remove or rename. Clients ignore unknown fields, so adding is safe.
{
"id": 42,
"name": "Ada",
"email": "ada@x.com"
}
// Later, safely add:
{
"id": 42,
"name": "Ada",
"email": "ada@x.com",
"created_at": "2026-01-01"
}Deprecation, Not Deletion
When you must retire something, deprecate first. Mark it in docs, send a Deprecation or Sunset header, and give clients a clear timeline before removal.
HTTP/1.1 200 OK
Deprecation: true
Sunset: Wed, 31 Dec 2026 23:59:59 GMT
Link: </v2/users>; rel="successor-version"Versioning gRPC and GraphQL
It is not just REST. In gRPC, never reuse or renumber protobuf field tags — that breaks the wire format. In GraphQL, the convention is no versions at all: add fields and use the @deprecated directive on old ones.
Supporting Multiple Versions
Running several versions at once has a cost. Strategies include translating old requests to the new internal model, or routing versions to different handlers. Limit how many versions you support and sunset old ones on schedule.
Designing for Change Up Front
Reduce future pain by designing for evolution: prefer objects over bare values so you can add fields, avoid leaking internal enums, and document a clear compatibility contract from day one.
Quick Check
Test your understanding of API versioning.
Recap
You learned how to evolve APIs safely:
- Distinguish breaking from non-breaking changes
- URI, header, and query parameter versioning schemes
- SemVer and the additive-change discipline
- Deprecate with Sunset headers before deleting
- gRPC tag stability and GraphQL's deprecation approach
Preguntas frecuentes
¿La lección «Versionado de API y compatibilidad con versiones anteriores» es gratis?
Sí — el texto completo de «Versionado de API y compatibilidad con versiones anteriores» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de System Design Basics for Backend Developers, actualiza a CoddyKit PRO. El curso de System Design Basics for Backend Developers incluye 4 lecciones en total.
¿Qué aprenderé en «Versionado de API y compatibilidad con versiones anteriores»?
Aprenda estrategias para evolucionar las API sin romper los clientes existentes, incluidos los esquemas de versionado y las reglas de compatibilidad. Practicas System Design Basics for Backend Developers con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.
¿Necesito experiencia previa para empezar System Design Basics for Backend Developers?
No se requiere experiencia previa. System Design Basics for Backend Developers en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 4 de 4.
¿Cuánto tiempo toma la lección «Versionado de API y compatibilidad con versiones anteriores»?
La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.
¿Puedo escribir y ejecutar código en esta lección de System Design Basics for Backend Developers?
Sí. Cada lección de System Design Basics for Backend Developers incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.
Todas las lecciones de este curso
- Principios de diseño de API RESTful
- GraphQL y gRPC
- Colas de mensajes y arquitecturas dirigidas por eventos
- Versionado de API y compatibilidad con versiones anteriores