5 REST API गलतियाँ जिन्होंने मुझे यूजर्स का नुकसान पहुँचाया
तीन साल पहले, मैंने अपना पहला पब्लिक API बनाया था। मुझे लगा कि यह एक वीकेंड में पूरा हो जाएगा। मैंने यूजर्स के आने का इंतज़ार किया।
वे आए। फिर वे चले गए।
प्रोडक्ट ठीक था। API का उपयोग करना कठिन था। मैंने पाँच बड़ी गलतियाँ की थीं। यहाँ बताया गया है कि मैंने उन्हें कैसे सुधारा।
- एरर (Errors) के लिए 200 OK का उपयोग करना जब चीजें विफल हो जाती थीं, तब भी मैं 200 OK स्टेटस भेजता था। मैं एरर मैसेज को JSON बॉडी के अंदर डाल देता था। इसकी वजह से डेवलपर्स को हर एक कॉल के लिए कस्टम लॉजिक लिखना पड़ता था।
समाधान: सही HTTP स्टेटस कोड का उपयोग करें।
- खराब इनपुट के लिए 400 का उपयोग करें।
- ऑथेंटिकेशन (auth) विफलताओं के लिए 401 का उपयोग करें।
- रिसोर्स न मिलने पर 404 का उपयोग करें।
- रेट लिमिट (rate limits) के लिए 429 का उपयोग करें।
- वर्जनिंग (Versioning) भूल जाना मैंने बिना किसी चेतावनी के अपने डेटा फील्ड्स बदल दिए। एक बदलाव ने मेरे सभी इंटीग्रेशन को तोड़ दिया।
समाधान: अपने रूट्स (routes) को /v1/ से प्रीफिक्स करें। यह आपके कोड को अपडेट करते समय मौजूदा क्लाइंट्स को टूटने से बचाता है। अपना वर्तमान वर्जन और एक पिछला वर्जन बनाए रखें।
- रेट लिमिटिंग (Rate Limiting) न होना एक बग वाले स्क्रिप्ट ने मेरे सर्च एंडपॉइंट (search endpoint) पर प्रति सेकंड 200 बार हिट किया। इसने मेरे डेटाबेस को पूरी तरह से व्यस्त (max out) कर दिया। इससे बाकी सभी लोगों के लिए सिस्टम क्रैश हो गया।
समाधान: रेट लिमिटिंग लागू करें। टोकन-बकेट (token-bucket) अप्रोच का उपयोग करें। Retry-After हेडर के साथ 429 Too Many Requests स्टेटस रिटर्न करें।
- असंगत एरर फॉर्मेट (Inconsistent Error Formats) एरर कहाँ हुआ है, इसके आधार पर मेरे एरर मैसेज अलग-अलग दिखते थे। एक एरर में "msg" का उपयोग किया जाता था जबकि दूसरे में "message" का। डेवलपर्स को एक ही API के लिए कई पार्सर (parsers) लिखने पड़ते थे।
समाधान: एक एरर स्ट्रक्चर चुनें और उसे हर जगह उपयोग करें। हर एरर में एक ही तरह की कीज़ (keys) होनी चाहिए।
- बहुत अधिक डेटा वापस करना (Returning Too Much Data) मेरा /users एंडपॉइंट डेटाबेस के हर यूजर को वापस भेजता था। जब हमारे यूजर्स की संख्या 10,000 तक पहुँची, तो रिस्पॉन्स साइज की वजह से मोबाइल ऐप्स क्रैश होने लगे।
समाधान: कर्सर-आधारित पेजिनेशन (cursor-based pagination) का उपयोग करें। यह रिस्पॉन्स को छोटा और स्थिर रखता है। यह बड़े डेटासेट्स के लिए ऑफसेट-आधारित पेजिनेशन (offset-based pagination) की तुलना में तेज़ है।
परिणाम:
- इंटीग्रेशन का समय 3 दिनों से घटकर 4 घंटे रह गया।
- सपोर्ट टिकटों में 70% की कमी आई।
- पुराने यूजर्स वापस आ गए।
आपका API ही आपका प्रोडक्ट है। एक अच्छा फ्रंटएंड एक खराब API को नहीं बचा सकता।
आपने अब तक की सबसे खराब API गलती कौन सी देखी है? मुझे कमेंट्स में बताएं।
स्रोत: https://dev.to/sirmax/5-rest-api-mistakes-that-cost-me-users-and-how-to-fix-them-57gi