Theory
वह Style जिसे ज़्यादातर APIs Follow करते हैं
जब आपकी app एक web service call करती है, वह service लगभग हमेशा एक particular style follow करती है: REST। REST समझने का मतलब है आप predict कर सकते हैं आपको मिलने वाली लगभग किसी भी API को कैसे इस्तेमाल करें, क्योंकि वे same conventions share करती हैं।
Express backend build करते समय आपने server side से REST देखा; यहाँ आप इसे एक consumer की तरह मिलते हैं, API को call करने वाली app। यह lesson REST की core ideas lay out करता है, resources, methods, statelessness, JSON, तो एक API की documentation पढ़ना और इसे correctly call करना second nature बन जाए। REST web APIs की lingua franca है।
At a glance
| Principle | इसका क्या मतलब है |
|---|---|
| URLs की तरह Resources | हर चीज़ का एक URL है: /events, /events/5 |
| Actions की तरह Methods | GET पढ़ता है, POST create करता है, PUT update करता है, DELETE remove करता है |
| Stateless | हर request अपनी ज़रूरत की हर चीज़ carry करती है; server requests के बीच कोई session नहीं रखता |
| JSON Data | Requests और responses typically JSON exchange करते हैं |
| Status Codes | Responses outcome report करते हैं: 200 OK, 404 Not Found, और ज़्यादा |
Theory
Resources, Methods, और JSON
REST में, एक URL एक resource (एक चीज़) को name करता है: /events events का collection है, /events/5 event 5 है। HTTP method बताता है इसके साथ क्या करना है: पढ़ने के लिए GET, create करने के लिए POST, update करने के लिए PUT, remove करने के लिए DELETE, वही nouns-in-the-URL, verbs-in-the-method idea जो आपने backend पर देखा।
Data दोनों तरफ़ JSON की तरह travel करता है, और हर response एक status code carry करता है (success के लिए 200, not found के लिए 404, वगैरह)। तो एक REST API से FestConnect के events fetch करने के लिए, आपकी app /events endpoint को एक GET भेजती है और वापस मिलने वाली JSON list parse करती है। Predictable और uniform, server चाहे जो भी हो।
Formula
Stateless: हर Request अकेली खड़ी है
एक defining REST principle है statelessness: हर request को वह सब कुछ carry करना पड़ता है जो server को इसे handle करने के लिए चाहिए, क्योंकि server requests के बीच आपकी app के बारे में कुछ भी याद नहीं रखता, requests को tie करने वाला कोई server-side session नहीं है।
तो अगर एक request को जानना है आप कौन हैं, यह हर बार आपका auth token include करती है; server आपको last call से 'याद' नहीं रखता। यह REST APIs को simple और scalable बनाता है (कोई भी server किसी भी request को handle कर सकता है, क्योंकि कोई भी stored client state पर rely नहीं करता)। आपकी app के लिए, इसका मतलब है: हर request को जो चाहिए वह include कीजिए, यह assume मत कीजिए server पिछली request याद रखता है।
Quiz
/events endpoint पर एक REST API से events की list पढ़ने के लिए, आपकी app कौन सा HTTP method इस्तेमाल करती है?
- POST, क्योंकि यह powerful है
- GET, क्योंकि GET REST में एक resource पढ़ता है (retrieve करता है)
- DELETE, क्योंकि यह data fetch करता है
- कोई method नहीं है; आप बस browser में URL open करते हैं
Show the answer
GET, क्योंकि GET REST में एक resource पढ़ता है (retrieve करता है)
REST में, GET एक resource पढ़ने (retrieve करने) का method है, तो events list fetch करना /events को एक GET request है। Option A wrong है: POST एक नया resource CREATE करने के लिए है (जैसे एक event add करना), पढ़ने के लिए नहीं; पढ़ने के लिए POST इस्तेमाल करना REST conventions violate करता है। Option C wrong है: DELETE एक resource remove करता है, इसे पढ़ने की opposite। Option D mechanism को misunderstand करता है: भले एक GET actually वह है जो एक browser करता है जब आप एक URL open करते हैं, आपकी APP GET programmatically perform करती है (Volley जैसी एक library के through) JSON receive करने के लिए, एक rendered page नहीं। Method को action से match कीजिए: पढ़ने के लिए GET, create करने के लिए POST, update करने के लिए PUT, remove करने के लिए DELETE।
Think first
एक API को Scale करने के लिए Statelessness अच्छा क्यों है?
REST servers requests के बीच आपकी app की कोई memory नहीं रखते। यह एक limitation की बजाय एक strength क्यों है? फिर tap कीजिए।
Show the answer
क्योंकि जब हर request SELF-CONTAINED है और server कोई per-client session store नहीं करता, कोई भी server किसी भी request को handle कर सकता है, जो system को scale करना कहीं ज़्यादा easy और ज़्यादा robust बनाता है। Imagine कीजिए एक popular API कई identical server machines से served हो रही है एक load balancer के पीछे। अगर servers को requests के बीच हर client के बारे में चीज़ें REMEMBER करनी पड़तीं (एक stateful session), फिर आपकी app की follow-up requests को उसी SAME server पर वापस जाना पड़ता जो आपका session hold करता है, या वह state सभी servers के across share और synchronise करना पड़ता, दोनों complicated, limiting, और fragile हैं (अगर वह server crash होता है, आपका session lost हो जाता है)। STATELESS REST के साथ, हर request server को जो चाहिए वह सब carry करती है (आप कौन हैं सहित, एक token के through), तो कोई फ़र्क़ नहीं पड़ता कौन सा server इसे handle करता है, requests आपको जितने चाहिए उतनी machines के across freely spread हो सकती हैं, और आप ज़्यादा load handle करने के लिए ज़्यादा servers add कर सकते हैं बिना session affinity की worry किए। यह servers को simpler भी बनाता है (manage करने के लिए कोई session store नहीं) और ज़्यादा resilient (एक server fail होना client state नहीं खोता, क्योंकि खोने के लिए कोई नहीं है)। Cost यह है कि हर request को कुछ information फिर से भेजनी पड़ती है (auth token जैसी) बजाय server के याद रखने पर rely करने के, scalability और reliability में बड़े gains के exchange में एक छोटा overhead। यही major reason है REST web के लिए dominant API style बना: statelessness APIs को ease से horizontally scale करने देता है। कोई stored session नहीं होने का मतलब है कोई भी server किसी भी request को serve कर सकता है, जो exactly वह है जो large-scale systems को चाहिए।
Summary
Key takeaways
- REST (Representational State Transfer) web APIs के लिए dominant architectural style है।
- Resources URLs से identify होते हैं (/events, /events/5); HTTP methods actions express करते हैं (GET, POST, PUT, DELETE)।
- REST stateless है: हर request अपनी ज़रूरत की हर चीज़ carry करती है, और server requests के बीच कोई client session नहीं रखता।
- Data typically JSON की तरह exchange होता है, और responses status codes carry करते हैं (200 OK, 404 Not Found)।
- Consumer side से, events fetch करना /events को एक GET है, फिर returned JSON parse करना।
- Statelessness किसी भी server को किसी भी request handle करने देता है, REST APIs को scale करने में simple और resilient बनाते हुए।
- Memory hook: URLs में resources, methods में actions, stateless requests, JSON data, status codes।