आपको एक public API में breaking change करना है। आप उसे version कैसे करेंगे और पुराना व्यवहार कैसे हटाएंगे?

पहले देखें कि टूटना ज़रूरी भी है या नहीं: fields जोड़ना और optional parameters स्वीकार करना backward compatible रहता है, बशर्ते क्लाइंट अनजान fields को नज़रअंदाज़ कर दें। अगर सच में टूटता है, तो साफ साफ version करें, आमतौर पर major versions के लिए path prefix, दोनों versions को एक ही internal model पर साथ साथ चलाएं, headers और per version metrics के साथ deprecation की समयसीमा घोषित करें, और पुराना तभी हटाएं जब उस पर ट्रैफ़िक लगभग शून्य हो जाए।

मेरा पहला कदम यह जांचना है कि टूटना ज़रूरी है या नहीं। कोई field जोड़ना, कोई optional parameter जोड़ना, या कोई enum value जोड़ना अगर क्लाइंट अनजान values सह लेते हैं, यह सब बिना version बढ़ाए जा सकता है। breaking का मतलब है कोई field हटाना या उसका नाम बदलना, validation कड़ी करना, या किसी मौजूदा value का अर्थ बदल देना। जब यह सचमुच breaking होता है, तो मैं path में major version रखता हूं, क्योंकि यह logs में दिखता है और क्लाइंट के लिए समझना आसान है, और पुराने version को मैं उसी internal model के ऊपर एक पतली translation layer की तरह रखता हूं ताकि मुझे दो implementations न संभालनी पड़ें। फिर वह हिस्सा आता है जिसमें असल में समय लगता है: per version per client requests instrument करना, response header और docs में sunset तारीख छापना, और सबसे बड़े callers से सीधे संपर्क करना। पिछली बार जो मैंने किया, उसमें v1 पर ट्रैफ़िक दो integrations से दिन में गिनी चुनी requests तक गिर गया, हमने संपर्क किया, और तीन महीने बाद उसे हटाना सुरक्षित था। per client metrics के बिना आप कभी कुछ delete नहीं कर पाते।