Backward Compatibility
BACKWARD-COMPATIBLE CHANGES (SAFE) — NAYE, OPTIONAL FIELDS, RESPONSE mein, ADD karna. NAYE ENDPOINTS, ADD karna. NAYE, OPTIONAL, QUERY PARAMETERS, ADD karna. IN CHANGES SE, EXISTING CLIENTS, BREAK NAHI hote, kyunki, WOH, NAYE FIELDS/PARAMETERS ko, IGNORE kar sakte hain.
BREAKING CHANGES (UNSAFE) — EXISTING FIELDS, RENAME/REMOVE karna. FIELD TYPES, CHANGE karna (jaise STRING SE, NUMBER). REQUIRED FIELDS, ADD karna. HTTP STATUS CODES, CHANGE karna. IN CHANGES ke liye, EK NAYI API VERSION (jaise /v2/), CREATE karni CHAHIYE, aur PURANI VERSION, EK "DEPRECATION PERIOD" ke SAATH, MAINTAIN karni CHAHIYE.
// SAFE — naya, optional field:
public class ProductDto {
private String name;
private BigDecimal price;
private String currency; // NAYA field, DEFAULT value ke saath — SAFE
}
// UNSAFE (breaking) — field rename:
// price → productPrice ❌ EXISTING clients, "price" field DHOONDТE rahenge, FAIL hoga
// UNSAFE — required field add karna:
// @NotBlank private String sku; ❌ PURANE clients, sku BHEJTE hi NAHI the- Safe changes = naye optional fields, naye endpoints
- Breaking changes = field rename/remove, required fields add karna
- Breaking changes ke liye, NAYI version banao — purani ko, deprecation period ke saath, maintain karo
NAYE, OPTIONAL FIELDS, RESPONSE mein, ADD karna, HAMESHA, SAFE hai — EXISTING, CLIENTS, JSON PARSERS, TYPICALLY, UNKNOWN, FIELDS ko, IGNORE kar dete hain (DEFAULT BEHAVIOR). YE, "ROBUSTNESS PRINCIPLE" (POSTEL'S LAW) FOLLOW karta hai.
Breaking, CHANGES ko, GRADUALLY, ROLLOUT karne ke liye, FEATURE FLAGS, USE kiye ja sakte hain — jaise, EK, HEADER (X-Beta-Features: new-response-format) SE, SIRF, OPT-IN, CLIENTS, NAYA, BEHAVIOR, EXPERIENCE karte hain, BAAKI, SAB, PURANA, BEHAVIOR, DEKHTE REHTE hain.
- Feature flags = gradual rollout, WITHOUT, breaking, EXISTING clients
- Opt-in headers = specific clients, NAYA behavior, TEST kar sakte hain