𝟵 𝗔𝗣𝗜 𝗖𝗵𝗮𝗻𝗴𝗲𝘀 𝗧𝗵𝗮𝘁 𝗕𝗿𝗲𝗮𝗸 𝗬𝗼𝘂𝗿 𝗔𝗽𝗽
"ನಾವು ಏನನ್ನೂ ಹಾಳು ಮಾಡಿಲ್ಲ. ನಾವು ಕೇವಲ ರೆಸ್ಪಾನ್ಸ್ ಅನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸಿದ್ದೇವೆ ಅಷ್ಟೆ."
ಆ ಮಾತುಗಳು ಹೆಚ್ಚಾಗಿ ಕ್ರ್ಯಾಶ್ಗಳಿಗೆ (crashes) ಕಾರಣವಾಗುತ್ತವೆ. ಒಂದು ಮೊಬೈಲ್ ಅಪ್ಲಿಕೇಶನ್ ವಿಫಲವಾಗುತ್ತದೆ. ಪಾರ್ಟ್ನರ್ ಇಂಟಿಗ್ರೇಷನ್ (partner integration) ಕಸದಂತಹ ಡೇಟಾವನ್ನು ನೀಡುತ್ತದೆ. ಇತರರು ಅವಲಂಬಿಸಿರುವ ಡೇಟಾದ ರೂಪವನ್ನು ನೀವು ಬದಲಾಯಿಸಿದ್ದೀರಿ.
ಅಪಾಯಕಾರಿ ಬದಲಾವಣೆಗಳು ಹೆಚ್ಚಾಗಿ ವ್ಯವಸ್ಥಿತವಾಗಿ ಮಾಡುವ ಕೆಲಸದಂತೆ ಕಾಣುತ್ತವೆ. ಅವು ಕೋಡ್ ರಿವ್ಯೂ ಮತ್ತು ಪರೀಕ್ಷೆಗಳಲ್ಲಿ (tests) ಪಾಸಾಗುತ್ತವೆ. ಆದರೆ ಸಮಸ್ಯೆ ನೀವು ನೋಡಲಾಗದ ಕೋಡ್ನಲ್ಲಿ ಸಂಭವಿಸುತ್ತದೆ.
ಸುರಕ್ಷಿತವೆಂದು ಅನಿಸುವ ಆದರೆ ಅಸಲಿ ವಿಷಯದಲ್ಲಿ ಸುರಕ್ಷಿತವಲ್ಲದ ಒಂಬತ್ತು ಬದಲಾವಣೆಗಳು ಇಲ್ಲಿವೆ.
ಫೀಲ್ಡ್ಗಳನ್ನು ಮರುನಾಮಕರಣ ಮಾಡುವುದು (Renaming fields) ಸ್ಥಿರತೆಗಾಗಿ
userIdಅನ್ನುuser_idಎಂದು ಬದಲಾಯಿಸುವುದು ಕ್ಲೈಂಟ್ಗಳನ್ನು (clients) ಹಾಳುಮಾಡುತ್ತದೆ. ಮರುನಾಮಕರಣ ಎಂದರೆ ಒಂದು ಫೀಲ್ಡ್ ಅನ್ನು ಡಿಲೀಟ್ ಮಾಡುವುದು ಮತ್ತು ಹೊಸದನ್ನು ಸೇರಿಸುವುದು ಎಂದರ್ಥ. ಆ ಡಿಲೀಟ್ ಮಾಡುವ ಭಾಗವೇ ಬಳಕೆದಾರರಿಗೆ ತೊಂದರೆ ನೀಡುತ್ತದೆ. ಸುರಕ್ಷಿತ ಕ್ರಮ: ಹೊಸ ಫೀಲ್ಡ್ ಅನ್ನು ಸೇರಿಸಿ. ಹಳೆಯದನ್ನು ಹಾಗೆಯೇ ಇರಿಸಿ. ಅದನ್ನು 'deprecate' ಮಾಡಿ. ಬಹಳ ಸಮಯದ ನಂತರ ಅದನ್ನು ತೆಗೆದುಹಾಕಿ.ಒಂದು ಫೀಲ್ಡ್ ಅನ್ನು ಆಪ್ಷನಲ್ (optional) ಮಾಡುವುದು ಒಂದು ಫೀಲ್ಡ್ ಮೊದಲು ಇರುತ್ತಿತ್ತು. ಈಗ ಅದು ಕೆಲವೊಮ್ಮೆ
nullಆಗಿರುತ್ತದೆ. ಕ್ಲೈಂಟ್ ಕೋಡ್ ಅದನ್ನು ಪ್ರೊಸೆಸ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಿದಾಗ ಕ್ರ್ಯಾಶ್ ಆಗುತ್ತದೆ. ಸುರಕ್ಷಿತ ಕ್ರಮ: "ಯಾವಾಗಲೂ ಇರುತ್ತದೆ" ಎಂಬುವುದನ್ನು ಒಂದು ಭರವಸೆಯಂತೆ ಪರಿಗಣಿಸಿ. ಒಂದು ಫೀಲ್ಡ್ ಆಪ್ಷನಲ್ ಆಗಬೇಕಿದ್ದರೆ, ಹೊಸ ವರ್ಷನ್ ಬಳಸಿ.ಬಳಕೆಯಲ್ಲいない ಫೀಲ್ಡ್ಗಳನ್ನು ತೆಗೆದುಹಾಕುವುದು ನಿಮ್ಮ ಗ್ರಾಹಕರು (consumers) ನಿಮ್ಮ ಡೇಟಾವನ್ನು ಹೇಗೆ ಬಳಸುತ್ತಾರೆ ಎಂಬುದು ನಿಮಗೆ ತಿಳಿಯುವುದಿಲ್ಲ. "ಬಳಕೆಯಲ್ಲಿಲ್ಲ" ಎಂದರೆ ಕೇವಲ ನೀವು ಬಳಸುತ್ತಿಲ್ಲ ಎಂದರ್ಥ. ಸುರಕ್ಷಿತ ಕ್ರಮ: ಏನನ್ನಾದರೂ ತೆಗೆದುಹಾಕುವ ಮೊದಲು ಪ್ರೊಡಕ್ಷನ್ನಲ್ಲಿ (production) ಆ ಫೀಲ್ಡ್ನ ಬಳಕೆಯನ್ನು ಅಳೆಯಿರಿ.
ಇನ್ಪುಟ್ ಟೈಪ್ಗಳನ್ನು ಕಿರಿದಾಗಿಸುವುದು (Narrowing input types) ಒಂದು
stringಅನ್ನುenumಆಗಿ ಅಥವಾ ಒಂದುnumberಅನ್ನುintegerಆಗಿ ಬದಲಾಯಿಸುವುದು ರಿಕ್ವೆಸ್ಟ್ಗಳನ್ನು (requests) ಹಾಳುಮಾಡುತ್ತದೆ. ಇನ್ಪುಟ್ ಅನ್ನು ವಿಸ್ತರಿಸುವುದು ಸುರಕ್ಷಿತ. ಆದರೆ ಅದನ್ನು ಕಿರಿದಾಗಿಸುವುದು ಒಂದು ಬ್ರೇಕಿಂಗ್ ಚೇಂಜ್ (breaking change). ಸುರಕ್ಷಿತ ಕ್ರಮ: ನೀವು ಸ್ವೀಕರಿಸುವ ಇನ್ಪುಟ್ಗಳನ್ನು ಸಡಿಲಗೊಳಿಸಿ ಮಾತ್ರ. ಬಿಗಿಗೊಳಿಸಲು ಹೊಸ ವರ್ಷನ್ ಅಗತ್ಯವಿದೆ.ಡಿಫಾಲ್ಟ್ ಮೌಲ್ಯಗಳನ್ನು ಬದಲಾಯಿಸುವುದು ಡಿಫಾಲ್ಟ್ ಅನ್ನು
falseನಿಂದtrueಗೆ ಬದಲಾಯಿಸುವುದು ಯಾವುದೇ ಎರರ್ ಇಲ್ಲದೆ ವರ್ತನೆಯನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ. ಇದು ಲಾಜಿಕ್ ಅನ್ನು ಮೌನವಾಗಿ ಹಾಳುಮಾಡುತ್ತದೆ. ಸುರಕ್ಷಿತ ಕ್ರಮ: ಡಿಫಾಲ್ಟ್ ಬದಲಾವಣೆಯನ್ನು ಬ್ರೇಕಿಂಗ್ ಚೇಂಜ್ ಆಗಿ ಪರಿಗಣಿಸಿ.ಅಗತ್ಯವಿರುವ (required) ಫೀಲ್ಡ್ಗಳನ್ನು ಸೇರಿಸುವುದು
tenantIdಅನ್ನು ಸೇರಿಸಿ ಅದನ್ನು 'required' ಮಾಡುವುದು ಪ್ರತಿಯೊಂದು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಕ್ಲೈಂಟ್ ಅನ್ನು ಹಾಳುಮಾಡುತ್ತದೆ. ಅವರಿಗೆ 400 ಎರರ್ ಬರುತ್ತದೆ. ಸುರಕ್ಷಿತ ಕ್ರಮ: ಹೊಸ ಫೀಲ್ಡ್ಗಳು ಆಪ್ಷನಲ್ ಆಗಿರಬೇಕು ಅಥವಾ ಹೊಸ ವರ್ಷನ್ ಬಳಸಿ.ಎರರ್ ಫಾರ್ಮ್ಯಾಟ್ಗಳನ್ನು ಬದಲಾಯಿಸುವುದು 400 ಅನ್ನು 422 ಗೆ ಬದಲಾಯಿಸುವುದು ಅಥವಾ ಎರರ್ ಬಾಡಿಯನ್ನು (error body) ಬದಲಾಯಿಸುವುದು ಎರರ್ ಹ್ಯಾಂಡ್ಲಿಂಗ್ ಕೋಡ್ ಅನ್ನು ಹಾಳುಮಾಡುತ್ತದೆ. ಸುರಕ್ಷಿತ ಕ್ರಮ: ಎರರ್ ಫಾರ್ಮ್ಯಾಟ್ಗಳು ಒಪ್ಪಂದಗಳಿದ್ದಂತೆ (contracts). ಉಳಿದವುಗಳಂತೆ ಇವುಗಳಿಗೂ ವರ್ಷನ್ ನೀಡಿ.
ಎನ್ಯೂಮ್ (enum) ಮೌಲ್ಯಗಳನ್ನು ಮಾರ್ಪಡಿಸುವುದು "active" ಅನ್ನು "ACTIVE" ಎಂದು ಮರುನಾಮಕರಣ ಮಾಡುವುದು ಕ್ಲೈಂಟ್ಗಳನ್ನು ಹಾಳುಮಾಡುತ್ತದೆ. ಒಂದು ಮೌಲ್ಯವನ್ನು ತೆಗೆದುಹಾಕುವುದು ಕಟ್ಟುನಿಟ್ಟಾದ ಲಾಜಿಕ್ ಹೊಂದಿರುವ ಕ್ಲೈಂಟ್ಗಳನ್ನು ಹಾಳುಮಾಡುತ್ತದೆ. ಸುರಕ್ಷಿತ ಕ್ರಮ: ಎನ್ಯೂಮ್ ಮೌಲ್ಯಗಳು ಶಾಶ್ವತ. ಅವುಗಳನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ಸೇರಿಸಿ. ಮೇಜರ್ ವರ್ಷನ್ ಇಲ್ಲದೆ ಅವುಗಳನ್ನು ಎಂದಿಗೂ ಮರುನಾಮಕರಣ ಮಾಡಬೇಡಿ ಅಥವಾ ತೆಗೆದುಹಾಕಬೇಡಿ.
ಡೇಟಾದ ಅರ್ಥವನ್ನು ಬದಲಾಯಿಸುವುದು ದಿನಾಂಕವನ್ನು Unix seconds ನಿಂದ ISO-8601 ಗೆ ಬದಲಾಯಿಸುವುದು ಅಥವಾ ಪೇಜಿನೇಷನ್ (pagination) ಅನ್ನು offset ನಿಂದ cursor ಗೆ ಬದಲಾಯಿಸುವುದು ಎಲ್ಲವನ್ನೂ ಹಾಳುಮಾಡುತ್ತದೆ. ಸ್ಕೀಮಾ ಡಿಫ್ (schema diff) ಕೂಡ ಇವುಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಸಾಧ್ಯವಾಗದಿರಬಹುದು. ಸುರಕ್ಷಿತ ಕ್ರಮ: ಫಾರ್ಮ್ಯಾಟ್ಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ನಿಗದಿಪಡಿಸಿ (Pin). ಕೇವಲ ಸ್ಪೆಕ್ (spec) ಅನ್ನು ಮಾತ್ರವಲ್ಲದೆ, ನೈಜ ಪೇಲೋಡ್ಗಳನ್ನು (payloads) ಹೋಲಿಸಿ ನೋಡಿ.
ಕೇವಲ ಅಂದಾಜಿನ ಮೇಲೆ ಅವಲಂಬಿತರಾಗಬೇಡಿ. ನಿಮ್ಮ CI ಯಲ್ಲಿ ಪ್ರತಿಯೊಂದು ಬದಲಾವಣೆಯನ್ನು ಪ್ರೊಡಕ್ಷನ್ ಕಾಂಟ್ರಾಕ್ಟ್ನೊಂದಿಗೆ ಹೋಲಿಸಿ ನೋಡಿ. ಮರುನಾಮಕರಣಗೊಂಡ ಫೀಲ್ಡ್ ಅನ್ನು ಮನುಷ್ಯರು ಗಮನಿಸದೆ ಬಿಡಬಹುದು, ಆದರೆ ಡಿಫ್ ಟೂಲ್ (diff tool) ತಪ್ಪಿಸುವುದಿಲ್ಲ.
ಮೂಲ: https://dev.to/deepaksatyam/9-api-changes-that-look-backwards-compatible-but-arent-1bk0