API Versioning Strategies
URI Versioning (SABSE COMMON) — /api/v1/products, /api/v2/products — SIMPLE, CLEAR, LEKIN, "TRUE REST" PRINCIPLE (URI, RESOURCE IDENTITY REPRESENT kare, VERSION NAHI) ko, THODA VIOLATE karta hai. Header Versioning — Accept: application/vnd.company.v2+json — URI, CLEAN RAHTA hai, LEKIN, TESTING/DEBUGGING, THODA HARDER hai (BROWSER mein, DIRECTLY, URL SE, TEST NAHI ho sakta).
Media-Type Versioning (CONTENT NEGOTIATION SE), EK VARIANT hai, HEADER VERSIONING KA — Accept HEADER mein, HI, VERSION, EMBED hoती hai. QUERY PARAMETER Versioning (?version=2) bhi, POSSIBLE hai, LEKIN, LESS COMMON.
// URI versioning — SABSE common:
@RestController
@RequestMapping("/api/v1/products")
public class ProductControllerV1 { }
@RestController
@RequestMapping("/api/v2/products")
public class ProductControllerV2 { }
// Header versioning:
@GetMapping(value = "/products", headers = "X-API-Version=2")
public ProductDtoV2 getProductV2() { }
@GetMapping(value = "/products", headers = "X-API-Version=1")
public ProductDtoV1 getProductV1() { }- URI versioning (/api/v1/) = simplest, MOST common, easy to test/debug
- Header versioning = URI clean rahta hai, LEKIN testing harder hai
- URI versioning, INDUSTRY mein, PRACTICAL DEFAULT hai
REAL-WORLD, APIs, AKSAR, MULTIPLE, VERSIONS, EK, SAATH, RUN karti hain — jaise, v1 aur v2, DONO, ACTIVE. INTERNALLY, v1 CONTROLLER, v2 SERVICE ko, DELEGATE kar sakta hai (AGAR, LOGIC, SAME hai), YA, COMPLETELY, SEPARATE, IMPLEMENTATION, RAKH sakta hai.
Deprecation aur Sunset, HTTP RESPONSE HEADERS SE, CLIENT ko, BATAYA ja sakta hai, KI, EK, VERSION, DEPRECATED hai, aur, KAB, REMOVE HOGA — jaise, Sunset: Sat, 31 Dec 2026 23:59:59 GMT.
response.setHeader("Deprecation", "true");
response.setHeader("Sunset", "Sat, 31 Dec 2026 23:59:59 GMT");
response.setHeader("Link", "</api/v2/products>; rel=\"successor-version\"");