एपीआई डिजाइन करने के तरीके पर कहानी

एक बार मैंने एक दोस्त की मदद की जिसे अपने क्लाइंट की साइट के साथ संपत्ति प्रबंधन प्रणाली से मुफ्त और कब्जे वाले आवास पर डेटा को एकीकृत करने की आवश्यकता थी। मेरी प्रसन्नता के लिए, इस प्रणाली में एक एपीआई था। लेकिन, दुर्भाग्य से, यह बहुत बुरी तरह से व्यवस्थित था।


मैंने इस लेख को उस प्रणाली की आलोचना करने के लिए नहीं लिखने का फैसला किया, जिस पर चर्चा की जाएगी, लेकिन इस बारे में बात करने के लिए कि एपीआई के विकास के दौरान क्या त्रुटियां हैं, और इन त्रुटियों को ठीक करने के तरीके सुझाते हैं।

स्थिति अवलोकन

प्रश्न में संगठन ने रहने वाले स्थान का प्रबंधन करने के लिए बेड्स 24 प्रणाली का उपयोग किया। वास्तव में क्या मुफ्त है और क्या व्यस्त है इसकी जानकारी आवास के लिए विभिन्न आरक्षण प्रणालियों (जैसे बुकिंग, AirBnB और अन्य) के साथ सिंक्रनाइज़ की गई थी। संगठन साइट के विकास में लगा हुआ था और वह चाहता था कि खोज केवल निर्दिष्ट अवधि के लिए उपलब्ध कमरों के बारे में जानकारी प्रदर्शित करे और क्षमता में उपयुक्त हो। यह कार्य बहुत सरल लग रहा था, क्योंकि बेड 24 अन्य प्रणालियों के साथ एकीकरण के लिए एक एपीआई प्रदान करता है। वास्तव में, यह पता चला कि इस एपीआई के डेवलपर्स ने इसके डिजाइन में बहुत सारी गलतियां की हैं। मैं इन त्रुटियों को पार्स करने का प्रस्ताव करता हूं, विशिष्ट समस्याओं की पहचान करता हूं और विचार के तहत स्थितियों में एपीआई के विकास के दृष्टिकोण के बारे में बात करता हूं।

समस्या # 1: शरीर प्रारूप का अनुरोध करें

चूंकि ग्राहक केवल इस बारे में जानकारी में रुचि रखता है कि क्या, कहते हैं, एक होटल का कमरा मुफ्त या व्यस्त है, हम केवल एपीआई /getAvailabilities संदर्भ में रुचि रखते हैं। और, हालांकि इस तरह के एक एपीआई को कॉल करने से कमरों की उपलब्धता पर डेटा का नेतृत्व करना चाहिए, यह कॉल, वास्तव में, एक POST अनुरोध की तरह दिखता है, क्योंकि एपीआई के लेखक ने इसे अनुरोध के JSON निकाय के रूप में फ़िल्टर स्वीकार करने की क्षमता से लैस करने का फैसला किया। यहां संभावित क्वेरी मापदंडों और उन मूल्यों के उदाहरणों की एक सूची दी गई है जिन्हें वे स्वीकार करते हैं:

 {   "checkIn": "20151001",   "lastNight": "20151002",   "checkOut": "20151003",   "roomId": "12345",   "propId": "1234",   "ownerId": "123",   "numAdult": "2",   "numChild": "0",   "offerId": "1",   "voucherCode": "",   "referer": "",   "agent": "",   "ignoreAvail": false,   "propIds": [       1235,       1236   ],   "roomIds": [       12347,       12348,       12349   ] } 

आइए इस JSON ऑब्जेक्ट के माध्यम से चलते हैं और यहां क्या गलत है के बारे में बात करते हैं।

1. दिनांक ( checkIn , lastNight और checkOut ) YYYYMMDD प्रारूप में हैं। तार को तारीखों में परिवर्तित करते समय मानक आईएसओ 8601 प्रारूप ( YYYY-MM-DD ) का उपयोग न करने का कोई कारण नहीं है, क्योंकि यह तारीखों को प्रस्तुत करने के लिए व्यापक रूप से उपयोग किया जाने वाला मानक है। यह कई डेवलपर्स से परिचित है, यह वही है जो इनपुट पर कई JSON पार्सर्स प्राप्त करने की उम्मीद करते हैं। इसके अलावा, एक भावना है कि lastNight फ़ील्ड निरर्थक है, क्योंकि एक checkOut फ़ील्ड है, जिसे हमेशा lastNight में निर्दिष्ट तारीख से एक दिन पहले की तारीख से lastNight । उपरोक्त उल्लिखित कमियों के संबंध में, मेरा सुझाव है, ऐसे एपीआई को डिजाइन करते समय, प्रस्तुत करने के मानक तरीकों का उपयोग करने के लिए हमेशा प्रयास करना चाहिए और अनावश्यक डेटा के साथ काम करने की आवश्यकता के साथ एपीआई उपयोगकर्ताओं को बोझ नहीं करना चाहिए।
2. सभी पहचानकर्ता फ़ील्ड, साथ ही numAdult और numChild संख्यात्मक होते हैं, लेकिन इन्हें स्ट्रिंग के रूप में दर्शाया जाता है। इस मामले में, उन्हें तार के रूप में प्रतिनिधित्व करने का कोई स्पष्ट कारण नहीं है।
3. यहां आप निम्नलिखित क्षेत्रों के जोड़े देख सकते हैं: roomId और roomIds , साथ ही propId और propIds । roomId और propId की उपस्थिति निरर्थक है, क्योंकि दोनों का उपयोग पहचानकर्ताओं को संचारित करने के लिए किया जा सकता है। इसके अलावा, प्रकार के साथ एक समस्या है। कृपया ध्यान दें कि roomId फ़ील्ड एक स्ट्रिंग फ़ील्ड है, और पहचानकर्ताओं के संख्यात्मक मान का उपयोग roomIds सरणी में किया जाना चाहिए। यह भ्रम पैदा कर सकता है, पार्सिंग के साथ समस्याएं, और, इसके अलावा, सुझाव देता है कि सर्वर पर कुछ संचालन स्ट्रिंग के साथ किए जाते हैं, और कुछ संख्याओं के साथ, इस तथ्य के बावजूद कि इन तारों और संख्याओं का उपयोग उसी का प्रतिनिधित्व करने के लिए किया जाता है। डेटा।

मैं एपीआई डेवलपर्स को आमंत्रित करना चाहूंगा कि वे उन एपीआई के जीवन को जटिल न करें जो एपीआई डिजाइन करते समय एपीआई जैसी गलतियां करते हैं। अर्थात्, किसी को मानक डेटा प्रारूपण के लिए प्रयास करना चाहिए, यह सुनिश्चित करने के लिए कि वे निरर्थक नहीं हैं, यह सुनिश्चित करने के लिए कि विभिन्न प्रकार के डेटा का उपयोग सजातीय संस्थाओं का प्रतिनिधित्व करने के लिए नहीं किया जाता है। और यह सब कुछ के लायक नहीं है, अंधाधुंध, लाइनों के रूप में प्रस्तुत करने के लिए।

समस्या # 2: प्रतिक्रिया स्वरूप

जैसा कि पहले ही उल्लेख किया गया है, हम केवल API /getAvailabilities में रुचि रखते हैं। आइए देखें कि इस समापन बिंदु का उत्तर कैसा दिखता है और इसके गठन के दौरान किन कमियों के बारे में बात करते हैं। याद रखें कि एपीआई तक पहुंचते समय, हम ऑब्जेक्ट पहचानकर्ताओं की एक सूची में रुचि रखते हैं जो किसी दिए गए समय के लिए स्वतंत्र हैं और दिए गए लोगों की संख्या को समायोजित कर सकते हैं। नीचे एपीआई के लिए अनुरोध के मुख्य भाग का एक उदाहरण है और इस अनुरोध के जवाब में इसका क्या रिटर्न है, इसका एक उदाहरण है।

यहाँ अनुरोध है:

 {   "checkIn": "20190501",   "checkOut": "20190503",   "ownerId": "25748",   "numAdult": "2",   "numChild": "0" } 

यहाँ जवाब है:

 {   "10328": {       "roomId": "10328",       "propId": "4478",       "roomsavail": "0"   },   "13219": {       "roomId": "13219",       "propId": "5729",       "roomsavail": "0"   },   "14900": {       "roomId": "14900",       "propId": "6779",       "roomsavail": 1   },   "checkIn": "20190501",   "lastNight": "20190502",   "checkOut": "20190503",   "ownerId": 25748,   "numAdult": 2 } 

प्रतिक्रिया मुद्दों के बारे में बात करें।

1. प्रतिक्रिया निकाय में, ownerId और संख्या numAdult अचानक संख्या बन गए। और अनुरोध में उन्हें तार के रूप में इंगित करना आवश्यक था।
2. रियल एस्टेट ऑब्जेक्ट्स की सूची ऑब्जेक्ट गुणों के रूप में प्रस्तुत की जाती है, जिनमें से कुंजी कमरे की पहचानकर्ता ( roomId ) हैं। यह उम्मीद करना तर्कसंगत होगा कि ऐसे डेटा एक सरणी के रूप में आउटपुट होंगे। हमारे लिए, इसका मतलब है कि उपलब्ध कमरों की एक सूची प्राप्त करने के लिए, हमें संपूर्ण ऑब्जेक्ट पर roomsavail करने की आवश्यकता है, जबकि इसमें संलग्न वस्तुओं की कुछ संपत्तियों की उपस्थिति की जाँच करना, जैसे कि roomsavail , और checkIn और lastNight जैसी किसी चीज़ पर ध्यान नहीं देना। तब roomsavail संपत्ति के मूल्य की जांच करना आवश्यक होगा, और यदि यह 0 से अधिक है, तो हम निष्कर्ष निकाल सकते हैं कि बुकिंग के लिए संबंधित संपत्ति उपलब्ध है। अब हम roomsavail संपत्ति पर नजर roomsavail हैं। यहां प्रतिक्रिया निकाय में इसे प्रस्तुत करने के लिए विकल्प दिए गए हैं: "roomsavail": "0" और "roomsavail": 1 । पैटर्न देखें? यदि कमरों पर कब्जा कर लिया जाता है, तो संपत्ति मूल्य एक स्ट्रिंग द्वारा दर्शाया जाता है। यदि मुक्त - यह एक संख्या में बदल जाता है। इससे भाषाओं में कई प्रकार की समस्याएं हो सकती हैं जो डेटा प्रकारों से सख्ती से संबंधित हैं, क्योंकि उनमें एक ही संपत्ति को विभिन्न प्रकारों के मूल्यों को नहीं लेना चाहिए। पूर्वगामी के संबंध में, मैं डेवलपर्स को JSON ऑब्जेक्ट्स के सरणियों का उपयोग करने के लिए कुछ डेटा सेटों का प्रतिनिधित्व करने के लिए सुझाव देना चाहूंगा, और जो हम यहां विचार कर रहे हैं, उसके समान महत्वपूर्ण-मूल्य वाले जोड़े के रूप में असुविधाजनक निर्माणों का उपयोग न करें। इसके अलावा, यह सुनिश्चित करना आवश्यक है कि सजातीय वस्तुओं के क्षेत्रों में विभिन्न प्रकार के डेटा शामिल नहीं हैं। एक ठीक से स्वरूपित सर्वर प्रतिक्रिया नीचे एक की तरह लग सकता है। कृपया ध्यान दें कि इस रूप में डेटा प्रस्तुत करते समय, कमरे की जानकारी में डुप्लिकेट डेटा नहीं होता है।

 {   "properties": [       {           "id": 4478,           "rooms": [               {                   "id": 12328,                   "available": false               }           ]       },       {           "id": 5729,           "rooms": [               {                   "id": 13219,                   "available": false               }           ]       },       {           "id": 6779,           "rooms": [               {                   "id": 14900,                   "available": true               }           ]       }   ],   "checkIn": "2019-05-01",   "lastNight": "2019-05-02",   "checkOut": "2019-05-03",   "ownerId": 25748,   "numAdult": 2 } 

समस्या 3: त्रुटि से निपटने

यह इस प्रकार है कि त्रुटि हैंडलिंग को यहां पर दिए गए एपीआई में आयोजित किया जाता है: सिस्टम सभी अनुरोधों के लिए 200 कोड के साथ प्रतिक्रिया भेजता है, भले ही कोई त्रुटि हो। इसका मतलब यह है कि एक त्रुटि संदेश के साथ एक प्रतिक्रिया से एक सामान्य प्रतिक्रिया को भेद करने का एकमात्र तरीका प्रतिक्रिया के शरीर को पार्स करना है और इसमें error या error फ़ील्ड की उपस्थिति के लिए जांच करना है। एपीआई में केवल निम्नलिखित 6 त्रुटि कोड दिए गए हैं।


बेड 24 एपीआई एपीआई कोड

मेरा सुझाव है कि जो कोई भी यह पढ़ता है वह 200 के कोड (अनुरोध के सफल प्रसंस्करण) के साथ प्रतिक्रिया वापस नहीं करने की कोशिश करता है अगर अनुरोध को संसाधित करते समय कुछ गलत हुआ। आप यह कदम तभी उठा सकते हैं जब यह फ्रेमवर्क द्वारा प्रदान किया जाता है जिसके आधार पर आप एपीआई विकसित कर रहे हैं। पर्याप्त प्रतिक्रिया कोड लौटाने से एपीआई ग्राहकों को अग्रिम में पता चलता है कि उन्हें प्रतिक्रिया निकाय को पार्स करने की आवश्यकता है या नहीं, और यह कैसे करना है (यानी, सामान्य सर्वर प्रतिक्रिया या त्रुटि ऑब्जेक्ट पार्स करने के लिए)।

हमारे मामले में, इस दिशा में एपीआई को बेहतर बनाने के दो तरीके हैं: आप या तो 6 संभावित त्रुटियों में से प्रत्येक के लिए 400-499 की सीमा में एक विशेष HTTP कोड प्रदान कर सकते हैं (ऐसा करने के लिए यह सबसे अच्छा है), या वापसी, यदि कोई त्रुटि होती है, तो कोड 500, जो अनुमति देगा कम से कम, ग्राहक को प्रतिक्रिया के शरीर का विश्लेषण करने से पहले पता होना चाहिए कि उसमें त्रुटि के बारे में जानकारी है।

समस्या संख्या 4: "निर्देश"

नीचे परियोजना प्रलेखन से एपीआई का उपयोग करने के लिए "निर्देश" हैं:

एपीआई का उपयोग करते समय कृपया निम्नलिखित निर्देशों को पढ़ें।

1. एपीआई कॉल को डिज़ाइन किया जाना चाहिए ताकि उनके निष्पादन के दौरान न्यूनतम मात्रा में डेटा भेजना और प्राप्त करना पड़े।
2. एपीआई कॉल एक समय में एक किया जाता है। अगली कॉल करने से पहले आपको API पर अगली कॉल तक इंतजार करना होगा।
3. यदि आपको एपीआई में कई कॉल करने की आवश्यकता है, तो उनके बीच कुछ सेकंड का ठहराव प्रदान किया जाना चाहिए।
4. एपीआई कॉल की आवश्यकता अक्सर नहीं होती है, क्लाइंट कार्यों को हल करने के लिए आवश्यक न्यूनतम स्तर पर कॉल का स्तर बनाए रखना।
5. 5-मिनट की अवधि में एपीआई के अत्यधिक उपयोग से आपके खाते का निलंबन बिना अतिरिक्त सूचना के हो जाएगा।
6. हम उन ग्राहकों तक सिस्टम की पहुँच को अवरुद्ध करने का अधिकार सुरक्षित रखते हैं, जो हमारी राय में, एपीआई का अत्यधिक उपयोग करते हैं। यह हमारे विवेक पर और बिना किसी नोटिस के किया जाता है।

जबकि अंक 1 और 4 काफी न्यायसंगत हैं, मैं इस निर्देश के अन्य बिंदुओं से सहमत नहीं हो सकता। उन पर विचार करें।

1. आइटम नंबर 2। यदि आप REST API विकसित कर रहे हैं, तो यह माना जाता है कि यह एक राज्य-स्वतंत्र API होगा। पिछले कॉल से एपीआई कॉल की स्वतंत्रता एक कारण है कि आरईएसटी प्रौद्योगिकी ने क्लाउड अनुप्रयोगों में व्यापक आवेदन पाया है। यदि सिस्टम का एक निश्चित मॉड्यूल राज्य का समर्थन नहीं करता है, तो इसे त्रुटि के मामले में आसानी से तैनात किया जा सकता है। ऐसे मॉड्यूल पर आधारित सिस्टम आसानी से बड़े पैमाने पर होते हैं जब उन पर भार बदल जाता है। RESTful API डिज़ाइन करते समय, आपको यह सुनिश्चित करना चाहिए कि यह एक स्टेट-इंडिपेंडेंट API है और इसका उपयोग करने वालों को एक समय में केवल एक अनुरोध निष्पादित करने जैसी किसी चीज़ के बारे में चिंता करने की ज़रूरत नहीं है।
2. आइटम नंबर 3। यह आइटम अजीब और अस्पष्ट दिखता है। मैं इस कारण को समझ नहीं सकता कि निर्देश का यह पैराग्राफ क्यों लिखा गया था, लेकिन मुझे यह महसूस होता है कि यह हमें बताता है कि अनुरोध को संसाधित करने की प्रक्रिया में, सिस्टम कुछ क्रियाएं करता है, और यदि यह दूसरे अनुरोध के द्वारा "विचलित" होता है, समय पर नहीं भेजा गया, इससे उसके काम में बाधा आ सकती है। इसके अलावा, यह तथ्य कि मैनुअल के लेखक का कहना है कि "कुछ सेकंड" हमें उस ठहराव की सही अवधि का पता लगाने की अनुमति नहीं देता है जो क्रमिक अनुरोधों के बीच निरंतर होना चाहिए।
3. आइटम नंबर 5 और नंबर 6। यह "एपीआई के अत्यधिक उपयोग" को संदर्भित करता है, लेकिन "अत्यधिक उपयोग" के लिए कोई मानदंड नहीं दिया गया है। शायद यह प्रति सेकंड 10 अनुरोध है? या शायद 1? इसके अलावा, कुछ वेब परियोजनाओं में भारी मात्रा में ट्रैफ़िक हो सकता है। अगर, बिना किसी पर्याप्त कारणों और अधिसूचना के, वे एपीआई की आवश्यकता के करीब पहुंचते हैं, तो उनके प्रशासक इस तरह के एपीआई का उपयोग करने से इनकार करेंगे। यदि आप इस तरह के निर्देश लिखते हैं, तो उनमें स्पष्ट भाषा का उपयोग करें और अपने उपयोगकर्ताओं को अपने सिस्टम के साथ काम करें, जिन्हें आपके निर्देशों द्वारा निर्देशित किया गया हो।

समस्या संख्या 5: प्रलेखन

यह वही है जो एपीआई प्रलेखन जैसा दिखता है।


बेड 24 एपीआई प्रलेखन

इस प्रलेखन के साथ एकमात्र समस्या इसकी उपस्थिति है। यह बहुत अच्छा लगेगा अगर इसे अच्छी तरह से स्वरूपित किया गया हो। विशेष रूप से इस तरह के दस्तावेज़ीकरण की संभावित उपस्थिति दिखाने के लिए, मैंने, डिलिंजर का उपयोग करते हुए, और उस पर दो मिनट से भी कम समय बिताया, इसका निम्न संस्करण बनाया। मेरी राय में, यह ऊपर की तुलना में बहुत बेहतर लग रहा है।


बेहतर प्रलेखन

ऐसी सामग्री बनाने के लिए, विशेष उपकरणों का उपयोग करने की सिफारिश की जाती है। यदि हम ऊपर वर्णित एक के समान सरल दस्तावेजों के बारे में बात कर रहे हैं, तो नियमित रूप से मार्कडाउन फ़ाइल की तरह कुछ उनके डिजाइन के लिए पर्याप्त है। यदि प्रलेखन अधिक जटिल है, तो इसके डिजाइन के लिए स्वैगर या एपरीर जैसे उपकरणों का उपयोग करना सबसे अच्छा है।

वैसे, अगर आप बेड 24 एपीआई के लिए प्रलेखन पर एक नज़र रखना चाहते हैं, तो यहां देखें ।

अंक 6: सुरक्षा

सभी एपीआई एंडपॉइंट्स के लिए प्रलेखन निम्नलिखित कहता है:

इन कार्यों का उपयोग करने के लिए, एपीआई तक पहुंच की अनुमति दी जानी चाहिए। यह मेनू SETTINGS → ACCOUNT → ACCOUNT ACCESS में किया जाता है।

हालांकि, वास्तव में, कोई भी इस एपीआई का उपयोग कर सकता है, और, कुछ कॉल का उपयोग करके, बिना किसी क्रेडेंशियल प्रदान किए, उससे जानकारी प्राप्त कर सकता है। उदाहरण के लिए, यह कुछ आवासों की उपलब्धता के बारे में प्रश्नों पर भी लागू होता है। यह प्रलेखन के दूसरे भाग में चर्चा की गई है।

अधिकांश JSON विधियों को किसी खाते तक पहुंचने के लिए API कुंजी की आवश्यकता होती है। एपीआई एक्सेस कुंजी को मेनू SETTINGS → ACCOUNT → ACCOUNT ACCESS के उपयोग से सेट किया जा सकता है।

प्रमाणीकरण मुद्दों की समझ से बाहर व्याख्या के अलावा, यह पता चलता है कि उपयोगकर्ता को एपीआई को अपने दम पर एक्सेस करने के लिए कुंजी बनाना होगा (यह किया जाता है, वैसे, मैन्युअल रूप से संबंधित क्षेत्र में भरने से, स्वचालित रूप से कुंजी बनाने के लिए कुछ साधन प्रदान नहीं किए जाते हैं)। प्रमुख लंबाई 16 और 64 वर्णों के बीच होनी चाहिए। यदि आप उपयोगकर्ताओं को एपीआई तक पहुंचने के लिए अपनी कुंजी बनाने की अनुमति देते हैं, तो इससे बहुत असुरक्षित कुंजियों की उपस्थिति हो सकती है जो आसानी से हो सकती हैं। एक समान स्थिति में, कुंजी की सामग्री से जुड़ी समस्याएं संभव हैं, क्योंकि आप कुंजी क्षेत्र में कुछ भी दर्ज कर सकते हैं। सबसे खराब स्थिति में, यह एसक्यूएल इंजेक्शन या ऐसा कुछ का उपयोग करके सेवा पर हमला कर सकता है। API डिज़ाइन करते समय, उपयोगकर्ताओं को स्वयं API तक पहुँचने के लिए कुंजियाँ बनाने की अनुमति न दें। इसके बजाय, स्वचालित रूप से उनके लिए कुंजी उत्पन्न करें। उपयोगकर्ता को ऐसी कुंजी की सामग्री को बदलने में सक्षम नहीं होना चाहिए, लेकिन, यदि आवश्यक हो, तो उसे एक नई कुंजी उत्पन्न करने में सक्षम होना चाहिए, पुराने को अमान्य मानते हुए।

प्रमाणीकरण की आवश्यकता वाले अनुरोधों के मामले में, हम एक और समस्या देखते हैं। यह इस तथ्य में शामिल है कि एक प्रमाणीकरण टोकन को अनुरोध निकाय के हिस्से के रूप में भेजा जाना चाहिए। यहाँ यह कैसे प्रलेखन में वर्णित है।


बेड 24 एपीआई प्रमाणीकरण उदाहरण

यदि प्रमाणीकरण टोकन अनुरोध निकाय में प्रेषित होता है, तो इसका अर्थ है कि सर्वर को कुंजी तक पहुंचने से पहले अनुरोध निकाय को पार्स करने की आवश्यकता होगी। उसके बाद, वह कुंजी निकालता है, प्रमाणीकरण करता है, और फिर निर्णय लेता है - उसे अनुरोध के साथ क्या करना चाहिए - इसे पूरा करने के लिए या नहीं। यदि प्रमाणीकरण सफल होता है, तो सर्वर अतिरिक्त लोड के अधीन नहीं होगा, क्योंकि इस मामले में अनुरोध निकाय को अभी भी पार्स करना होगा। लेकिन अगर अनुरोध प्रमाणित करने में विफल रहा है, तो मूल्यवान प्रोसेसर समय कुछ भी नहीं के लिए अनुरोध निकाय को पार्स करने पर खर्च किया जाएगा। बियरर प्रमाणीकरण योजना जैसी किसी चीज़ का उपयोग करके अनुरोध हेडर में प्रमाणीकरण टोकन भेजना बेहतर होगा। इस दृष्टिकोण के साथ, प्रमाणीकरण अनुरोध सफल होने पर ही सर्वर को अनुरोध निकाय को पार्स करने की आवश्यकता होगी। एक और कारण है कि हम प्रमाणीकरण के लिए बियरर जैसी मानक योजना का उपयोग करने की सलाह देते हैं, यह तथ्य है कि अधिकांश डेवलपर्स ऐसी योजनाओं से परिचित हैं।

समस्या संख्या 7: प्रदर्शन

यह मेरी सूची का अंतिम मुद्दा है, लेकिन यह इसके महत्व से अलग नहीं है। तथ्य यह है कि एपीआई में अनुरोध को पूरा करने में एक सेकंड से थोड़ा अधिक समय लगता है। आधुनिक अनुप्रयोगों में, इस तरह की देरी अस्वीकार्य हो सकती है। तथ्य की बात के रूप में, यहां आप एपीआई के विकास में शामिल सभी को सलाह दे सकते हैं कि वे प्रदर्शन के बारे में न भूलें।

परिणाम

उन सभी समस्याओं के बावजूद, जिनके बारे में हम यहां बात कर रहे थे, एपीआई में सवाल ने हमें परियोजना के सामने आने वाली समस्याओं को सुलझाने की अनुमति दी। लेकिन डेवलपर्स को एपीआई को समझने और उनकी जरूरत की हर चीज को लागू करने में काफी समय लगा। इसके अलावा, सरल समस्याओं को हल करने के लिए, उन्हें जटिल कोड लिखना था। यदि इस एपीआई को डिज़ाइन किया गया था, तो यह काम तेजी से किया जाएगा, और टर्नकी समाधान सरल होगा।

इसलिए, मैं उन सभी लोगों से पूछना चाहता हूं जो एपीआई के डिजाइन के बारे में सोचते हैं कि उनकी सेवाओं के उपयोगकर्ता इसके साथ कैसे काम करेंगे। सुनिश्चित करें कि एपीआई के लिए प्रलेखन पूरी तरह से उनकी क्षमताओं का वर्णन करता है, ताकि यह समझने योग्य और अच्छी तरह से डिज़ाइन किया गया हो। संस्थाओं के नामकरण को नियंत्रित करें, सुनिश्चित करें कि आपके एपीआई का डेटा जो प्राप्त करता है या प्राप्त करता है वह स्पष्ट रूप से संरचित है ताकि उनके साथ काम करना आसान और सुविधाजनक हो। इसके अलावा, सुरक्षा और त्रुटियों की सही हैंडलिंग के बारे में मत भूलना। यदि आप एपीआई को डिजाइन करते समय हमारी हर बात को ध्यान में रखते हैं, तो आपको उस अजीब "निर्देश" जैसा कुछ लिखने की जरूरत नहीं है, जिसके बारे में हमने इसके साथ काम करने के लिए ऊपर चर्चा की है।

जैसा कि पहले ही उल्लेख किया गया है, इस सामग्री का उद्देश्य पाठकों को बेडस 24 या किसी अन्य सिस्टम को खराब डिज़ाइन किए गए एपीआई का उपयोग करने से हतोत्साहित करना नहीं है। मेरा लक्ष्य सिफारिशों को देने के लिए गलतियों और उनके समाधान के दृष्टिकोण को प्रदर्शित करना था, जिसके बाद हर कोई अपने विकास की गुणवत्ता में सुधार कर सकता था। मुझे उम्मीद है कि यह सामग्री उन प्रोग्रामर्स का ध्यान आकर्षित करेगी जो इसे विकसित किए गए समाधानों की गुणवत्ता के लिए पढ़ते हैं। इसका मतलब यह है कि दुनिया में अधिक अच्छे एपीआई होंगे।

प्रिय पाठकों! क्या आप खराब डिज़ाइन किए गए API में आए हैं?