Theory
Trust करने से पहले API Test कीजिए
आप एक events API call करने वाला Android code लिखने वाले हैं। पर क्या हो अगर API आपकी expectation से differently behave करे, एक अलग field name, एक अलग structure, एक error? अगर आप इसे सिर्फ़ अपनी app के अंदर से ही call करते हैं, एक failure API की गलती हो सकती है या आपकी app की, और आपको पता नहीं होगा कौन सी।
Professional habit है पहले API को अपने-आप test करना, Postman जैसे एक tool से। यह lesson explain करता है API testing tools क्या करते हैं और एक endpoint independently test करना आपके hours की confusion क्यों बचाता है। इसके against build करने से पहले जानिए API काम करती है।
Theory
एक API Testing Tool क्या करता है
Postman जैसा एक tool आपको कोई app code लिखे बिना HTTP requests एक API को भेजने देता है। आप method (GET, POST), URL (endpoint), कोई भी headers (एक auth token जैसे), और, POST के लिए, एक body set करते हैं, फिर send hit करते हैं।
यह आपको exact response दिखाता है: body (return हुआ JSON), status code (200, 404, 401), headers, और यह कितना समय लिया। तो आप precisely देख सकते हैं API क्या expect करती है और क्या return करती है, Android code की एक भी line commit करने से पहले। (Command-line tool curl एक terminal से यही करता है।) एक API explore और confirm करने का यह एक fast, direct तरीका है।
Formula
Fault Isolate कीजिए: API या App?
Biggest payoff है isolation। जब आपकी app data पाने में fail होती है, cause API हो सकता है (down, changed, एक अलग request चाहिए) या आपकी app (wrong URL, bad parsing, missing header)। Postman में endpoint test करना इसका instantly जवाब देता है: अगर Postman को सही response मिलता है, API ठीक है और bug आपकी app में है; अगर Postman भी fail होता है, problem API में है या इसे आपकी request में है।
वह एक check enormous time बचाता है, आप guess करना बंद कर देते हैं और जानते हैं कहाँ देखना है। समझने के लिए पहले test कीजिए, और debug करने के लिए फिर test कीजिए: यह API है, या मैं हूँ?
Quiz
अपनी Android app इसके against build करने से पहले और दौरान Postman जैसे एक tool से एक API क्यों test करें?
- क्योंकि Postman आपके लिए Android code लिखता है
- API के exact requests और responses independently देखने के लिए, confirm करने के लिए यह काम करती है, और isolate करने के लिए बाद की problem API है या आपकी app
- क्योंकि apps Postman के बिना APIs call नहीं कर सकतीं
- App का data permanently store करने के लिए
Show the answer
API के exact requests और responses independently देखने के लिए, confirm करने के लिए यह काम करती है, और isolate करने के लिए बाद की problem API है या आपकी app
Postman (और similar tools) आपको बिना app code के requests भेजने और exact responses और status codes inspect करने देते हैं, तो आप इसके against build करने से पहले API समझ और confirm कर सकते हैं, और बाद में isolate कर सकते हैं एक failure API में है या आपकी app में। Option A wrong है: Postman APIs test करता है; यह आपका Android code generate नहीं करता। Option C false है: आपकी app APIs directly call करती है (Volley वगैरह के through); Postman एक testing aid है, app को requests करने के लिए requirement नहीं। Option D wrong है: Postman requests test करने के लिए है, app data store करने के लिए नहीं। Value है API को समझना और de-risk करना, और faults जल्दी pinpoint करना।
Think first
API को अलग से Test करना इतना Debugging Time क्यों बचाता है?
सब कुछ app के अंदर ही debug क्यों न करें? API अकेले test करना क्या add करता है? फिर tap कीजिए।
Show the answer
क्योंकि एक पूरे app-plus-API system को एक साथ debug करना आपको एक साथ MANY possible causes consider करने को force करता है, जबकि API अकेले test करना problem को दो छोटे, independent parts में SPLIT करता है जिन्हें आप एक-एक करके check कर सकते हैं, जो कहीं ज़्यादा fast है। जब आपकी app कोई data नहीं दिखाती, failure एक लंबी chain में कहीं भी हो सकती है: एक wrong endpoint URL, एक missing या malformed header, API down या changed होना, एक non-200 status, एक response जिसकी shape आपकी parsing की expectation से अलग है, एक threading या callback mistake, या एक UI bug। एक साथ इन सब को hunt करना slow और confusing है। Postman में endpoint test करना chain को cleanly दो में cleave करता है। अगर Postman को correct response मिलता है, आपने PROVE कर दिया API और request ठीक हैं, तो bug MUST आपकी तरफ़ होना चाहिए (code में URL, headers, parsing, या display), और आप पूरे 'क्या server ok है?' आधे को ignore कर सकते हैं। अगर Postman भी fail होता है या कुछ unexpected return करता है, आपने prove कर दिया problem API में है या इसे आपकी request में है, तो आप अपने app code में search करना पूरी तरह बंद कर देते हैं। किसी भी तरह, एक quick test आधी possibilities eliminate करता है, और आप अक्सर exact issue देख सकते हैं (401 का मतलब auth है, 404 का मतलब wrong URL है, एक differently-shaped body का मतलब है अपनी parsing fix कीजिए)। यह 'divide and conquer' एक fundamental debugging strategy है: components को isolate कीजिए और उन्हें independently verify कीजिए तो आप fault जल्दी localise कर सकें। API को अलग से test करना app-plus-service integration पर applied वही strategy है, यही वजह है professionals routinely यह करते हैं। System split कीजिए, हर half test कीजिए, और bug खुद reveal हो जाता है।
Summary
Key takeaways
- अपनी app इसके against build करने से पहले और दौरान एक API अपने-आप test कीजिए।
- Postman (या curl) जैसे tools बिना app code के HTTP requests भेजते हैं और response body, status code, headers, और timing दिखाते हैं।
- आप method, URL, headers, और body set करते हैं, फिर precisely inspect करते हैं API क्या expect करती है और क्या return करती है।
- यह आपको Android code लिखने से पहले confirm करने देता है API काम करती है और इसकी request/response shape समझने देता है।
- Debug करते समय, endpoint test करना fault isolate करता है: अगर Postman काम करता है, bug आपकी app में है; अगर नहीं, यह API या आपकी request है।
- Components isolate करना (divide and conquer) debugging कहीं ज़्यादा fast बनाता है।
- Memory hook: पहले API अकेले test कीजिए, फिर आप हमेशा जानते हैं एक failure API है या आपकी app।