मॉड्यूल 13 · HTTP और वेब के मूल सिद्धांत

HTTP मेथड्स

Mutqan Soft QA टीम द्वारा · · 18 मिनट · शुरुआती

HTTP method हर request line का पहला शब्द है: यह server को बताता है कि client target resource के साथ क्या करवाना चाहता है; resource वह चीज़ है जिसे URI पहचानता है, जैसे कोई order। GET /orders/42 order 42 माँगता है, जबकि DELETE /orders/42 server से उसे हटाने को कहता है। URI वही है, लेकिन मतलब, expected response और risk पूरी तरह अलग हैं।

HTTP Semantics standard, यानी RFC 9110, GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS और TRACE परिभाषित करता है, और RFC 5789 इनमें PATCH जोड़ता है। हर method का एक तय अर्थ है और दो properties हैं जिन पर tester भरोसा करता है: क्या वह safe है और क्या वह idempotent है। यह lesson उन सात methods को कवर करता है जो web applications और APIs रोज़ इस्तेमाल करते हैं।

यह क्यों ज़रूरी है

Method user और server के बीच मौजूद हर program से किया गया एक वादा है। Search crawlers और link-preview services GET links खोलती हैं, browsers pages पहले से fetch करते हैं, और HTTP clients connection टूटने पर idempotent request अपने-आप दोबारा भेज सकते हैं। यह तभी तक हानिरहित है जब तक application वादा निभाए: GET link के पीछे रखा delete action कोई crawler भी चला सकता है।

Tester के लिए methods हर endpoint की expectations की तैयार list बन जाते हैं: क्या state नहीं बदलना चाहिए, क्या दो बार भेजा जा सकता है और कौन-से methods reject होने चाहिए। Duplicate orders, fields मिटा देने वाले updates और records delete कर सकने वाले साधारण users अक्सर सिर्फ़ method बदलकर या वही request दो बार भेजकर पकड़े जाते हैं।

सात methods जिन्हें आप टेस्ट करेंगे

नीचे दिए responses आम हैं; exact codes API contract तय करता है। RFC 9110 CONNECT (proxy के ज़रिए tunnel) और TRACE (diagnostics के लिए request वापस लौटाना) भी परिभाषित करता है, जिन्हें application के अंदर शायद ही टेस्ट किया जाता है। Method names case-sensitive हैं; standard methods uppercase में लिखे जाते हैं।

  • GET resource का representation लाता है, यानी JSON या HTML जैसे format में उसकी मौजूदा state, आम तौर पर 200 OK के साथ। RFC 9110 में GET के साथ भेजे गए content का कोई तय अर्थ नहीं है, और कुछ servers उसे reject कर देते हैं।
  • HEAD बिना response body वाला GET है। Server को वही headers भेजने चाहिए जो वह GET पर भेजता, ताकि client resource का होना, उसका size या type बिना download किए जाँच सके। हर general-purpose server के लिए GET और HEAD support करना ज़रूरी है।
  • POST content भेजता है जिसे resource अपने नियमों से process करता है: /orders में order बनाना, form submit करना, या /orders/42/cancel जैसा action शुरू करना। अगर POST कुछ बनाता है तो Location header के साथ 201 Created अपेक्षित है।
  • PUT body में दी गई पूरी state से resource बनाता या replace करता है: replace होने पर 200 या 204, नया बनने पर 201।
  • PATCH (RFC 5789) एक patch document में बताए बदलाव लागू करता है, इसलिए सिर्फ़ वही बदलता है जिसका document में ज़िक्र है। Format Content-Type बताता है, जैसे application/merge-patch+json।
  • DELETE resource हटाता है: आम तौर पर 204 No Content, message के साथ 200, या deletion queue में जाने पर 202 Accepted। GET की तरह, DELETE request में भेजे गए content का भी कोई तय अर्थ नहीं है।
  • OPTIONS पूछता है कि resource कौन-से methods और features support करता है; जवाब Allow जैसे headers में आता है। Browsers इसे CORS preflight के रूप में खुद भी भेजते हैं, जिसे CORS वाला lesson समझाता है।

आज़माएँ: HTTP रिक्वेस्ट इंस्पेक्टर आज़माएँ: cURL जनरेटर

Safe और idempotent: RFC 9110 के दो वादे

कोई method safe तब है जब उसका अर्थ read-only हो: client server की state में न कोई बदलाव माँगता है, न उसकी उम्मीद करता है। GET, HEAD, OPTIONS और TRACE safe हैं। Request को log करना या page view गिनना फिर भी allowed है। RFC 9110 page?do=delete जैसे link का उदाहरण देता है: अगर उसे खोलने से data delete होता है, तो गलती resource की है, उस crawler की नहीं जिसने link खोला।

कोई method idempotent तब है जब वही request कई बार भेजने का server पर intended effect उतना ही हो जितना एक बार भेजने का। PUT, DELETE और सभी safe methods idempotent हैं; POST नहीं है, और PATCH आम तौर पर नहीं है। Address को दो बार set करने पर एक ही address रहता है; "एक item जोड़ो" दो बार भेजने पर दो items जुड़ जाते हैं। Idempotency server की state के बारे में है, response के बारे में नहीं: दूसरा DELETE 404 लौटाकर भी सही हो सकता है।

RFC 9110 response आने से पहले connection fail होने पर idempotent request को अपने-आप दोहराने की अनुमति देता है, और कहता है कि client non-idempotent request को अपने-आप retry न करे, जब तक उसे पता न हो कि request असल में idempotent है या लागू ही नहीं हुई थी। Safe का मतलब secure नहीं: GET को भी authorization चाहिए, और sensitive data उसके URI में नहीं होना चाहिए, क्योंकि servers, proxies और browsers URI record करते हैं।

GET, HEAD और OPTIONS safe और idempotent हैं, PUT और DELETE state बदलते हैं पर idempotent हैं, और POST व आम तौर पर PATCH दोनों में से कुछ नहीं, इसलिए clients को इन्हें अपने-आप retry नहीं करना चाहिए।
MethodSaferead-only अर्थIdempotentदोहराना = वही असरRequest bodyआम success response
GETपढ़नाहाँहाँकोई तय अर्थ नहीं200 OKrepresentation के साथ
HEADसिर्फ़ headersहाँहाँकोई तय अर्थ नहीं200 OKGET वाले headers, body नहीं
OPTIONSक्या supported हैहाँहाँकोई तय उपयोग नहीं200 या 204Allow के साथ
PUTबनाना या replaceनहींहाँपूरी नई state200 या 204नया बनने पर 201
DELETEहटानानहींहाँकोई तय अर्थ नहीं204, 200 या 202queue होने पर 202
POSTcontent process करनानहींनहींprocess होने वाला content201 Createdकुछ बनने पर, Location के साथ
PATCHआंशिक बदलावनहींआम तौर पर नहींकोई ख़ास patch हो सकता हैPatch document200 या 204

Properties RFC 9110 के अनुसार, PATCH RFC 5789 के अनुसार। Status codes आम वाले हैं; exact codes API contract तय करता है।

पाठ संस्करण
Method   Safe  Idempotent      Request body         Typical success response
-------  ----  --------------  -------------------  -------------------------------
GET      yes   yes             no defined meaning   200 + the representation
HEAD     yes   yes             no defined meaning   200, same headers as GET, no body
OPTIONS  yes   yes             no defined use       200 or 204 + Allow
PUT      no    yes             full new state       200 or 204; 201 if it created
DELETE   no    yes             no defined meaning   204, 200, or 202 if queued
POST     no    no              content to process   201 + Location if it created
PATCH    no    not in general  patch document       200 or 204

हर method में क्या टेस्ट करें

हर वादे को test conditions में बदलें। हर request के बाद दो चीज़ें जाँचें: response, और resource की state, जिसे अलग GET से या database से पढ़ें।

  • GET और HEAD: कितनी भी बार भेजें, कुछ नहीं बदलता। HEAD वही status और headers लौटाता है जो GET लौटाता है, पर body खाली रहती है। GET links में छिपे actions ढूँढें, जैसे ?action=cancel।
  • POST: वही request दो बार भेजें, जैसा double-click या retry में होता है, और team के साथ तय हुआ duplicate नियम टेस्ट करें: reject, merge या accept। कुछ APIs client का बनाया key लेते हैं, अक्सर Idempotency-Key header में, ताकि दोहराई गई request पहचानी जा सके।
  • PUT: दो बार भेजें और एक ही stored state की उम्मीद करें। कोई optional field हटा दें: contract के अनुसार field खाली हो जाए या request reject हो; पुरानी value चुपचाप बनी रहने का मतलब है कि PUT partial update की तरह लागू हो रहा है।
  • PATCH: request से पहले और बाद में पूरा resource compare करें; जो fields आपने नहीं भेजे वे नहीं बदलने चाहिए। Unsupported patch format पर 415 Unsupported Media Type आना चाहिए, साथ में Accept-Patch header, जैसा RFC 5789 सुझाता है।
  • DELETE: उसके बाद GET 404 लौटाता है, दोबारा DELETE कुछ और नहीं बदलता, और related data requirement के अनुसार handle होता है।
  • Unsupported methods: Allow header के साथ 405 Method Not Allowed की उम्मीद करें, जिसे RFC 9110 ज़रूरी बनाता है, या ऐसे method पर 501 Not Implemented जिसे server पहचानता ही नहीं। 200 या 500 defect है, और OPTIONS को वही methods बताने चाहिए जो सच में काम करते हैं।
  • हर method पर authorization: जो user किसी record को GET कर सकता है, ज़रूरी नहीं कि वह उसे PUT या DELETE भी कर सके। Write methods को कम privilege वाले account से दोहराएँ; OWASP API Security Top 10 (2023) इस risk को Broken Function Level Authorization कहता है। सिर्फ़ वही systems टेस्ट करें जो आपके हैं या जिनके लिए आपके पास लिखित अनुमति है।

आज़माएँ: API रिक्वेस्ट बिल्डर आज़माएँ: HTTP स्टेटस कोड लुकअप

Worked example: एक endpoint, हर method

एक address-book API /v1/addresses/{id} पर GET, HEAD, OPTIONS, PUT, PATCH और DELETE document करता है, और address 7 user A का है। "Address update करें" जैसे एक अस्पष्ट test की बजाय tester हर वादे के लिए एक row लिखता है, और हर row में status code के साथ stored state भी जाँचता है:

  • Row 4 PUT को PATCH से अलग करती है: पुराना city बना रहना मतलब PUT partial update की तरह लागू हो रहा है।
  • Row 8 तब चलती है जब address 7 अभी मौजूद है; वहाँ 204 का मतलब है कि user B किसी दूसरे user का data delete कर सकता है, और यह एक critical authorization defect है।
#   Request (as user A unless stated)       Expected result
1   GET /v1/addresses/7, sent twice         200 both times, same body, nothing changed
2   HEAD /v1/addresses/7                    200, same headers as GET, empty body
3   PUT /v1/addresses/7 (full body), twice  200 or 204 both times, one stored address
4   PUT /v1/addresses/7 without "city"      4xx (city is required), address unchanged
5   PATCH /v1/addresses/7 {"zip": "12271"}  200, only zip changed; street and city kept
6   POST /v1/addresses/7                    405 + Allow: GET, HEAD, OPTIONS, PUT, PATCH,
                                            DELETE
7   OPTIONS /v1/addresses/7                 200 or 204, Allow lists the same six methods
8   DELETE /v1/addresses/7 as user B        403 or 404, address 7 still exists
9   DELETE /v1/addresses/7                  204, then GET returns 404
10  DELETE /v1/addresses/7 again            404 as documented, no other address affected

आज़माएँ: REST API टेस्टर

आम गलतियाँ

  • "Safe" को "secure" समझना। Safe का मतलब सिर्फ़ इतना है कि client बदलाव नहीं माँगता; GET को भी authentication और authorization चाहिए।
  • हर POST सिर्फ़ एक बार भेजना। Double submission और retries duplicate orders और payments की एक आम वजह हैं।
  • Idempotent method से एक जैसे responses की उम्मीद करना। दोहराया गया DELETE 404 लौटा सकता है; idempotency server की state के बारे में है।
  • PUT और PATCH को एक जैसा मानना, और न भेजे गए fields को कभी न जाँचना।
  • सिर्फ़ वही methods टेस्ट करना जो user interface इस्तेमाल करता है। कोई भी client कोई भी method भेज सकता है, इसलिए जाँचें कि बाक़ी methods को Allow के साथ 405 मिले।

QA का नज़रिया

Methods code लिखे जाने से पहले की review checklist हैं। किसी story या API contract के हर endpoint के methods लिखें और पूछें: server पर क्या बदलता है? क्या request दोहराई जा सकती है? Duplicate आने पर क्या होता है? Web और mobile developers से पूछें कि क्या उनके clients timeout के बाद retry करते हैं; mobile networks पर दोबारा भेजा गया POST एक असली scenario है।

हर test case और bug report में method का नाम लिखें: "address update करें" का मतलब PUT भी हो सकता है और PATCH भी, और method के बिना request replay नहीं की जा सकती। Roles वाले endpoints के लिए method × role की एक छोटी table रखें, हर cell में expected status के साथ, और permissions बदलने पर उसे फिर चलाएँ।

अभ्यास

Shop cart API के methods review करें

आपका काम

आप staging पर एक shop API टेस्ट कर रहे हैं। नीचे दिए contract के हिस्से और छह observations के आधार पर बताएँ कि हर documented method safe और idempotent है या नहीं, फिर हर observation के लिए तय करें कि वह defect है या नहीं, असल में क्या होना चाहिए और क्यों।

सामग्री
Contract excerpt
GET    /v1/cart                  read the cart
POST   /v1/cart/items            add an item, body {"sku": "A1", "qty": 1}
PUT    /v1/cart/items/{sku}      set the quantity of an item, body {"qty": 2}
DELETE /v1/cart/items/{sku}      remove an item
PATCH  /v1/profile               change some profile fields
GET    /v1/coupons/apply?code=X  apply a coupon to the cart

Observations
a  PUT /v1/cart/items/A1 {"qty": 2}, sent twice  -> quantity is 4
b  Opening /v1/coupons/apply?code=SAVE10 twice    -> discount applied twice
c  HEAD /v1/cart                                  -> 200 with the full JSON body
d  DELETE /v1/cart (not in the contract)          -> 500 Internal Server Error
e  PATCH /v1/profile {"phone": "0550000000"}      -> 200, "email" is now null
f  POST /v1/cart/items, retried after a timeout   -> the same item appears twice
चरण
  1. Contract की हर line को safe या नहीं, और idempotent या नहीं, mark करें।
  2. हर observation की तुलना उसके method के वादे से करें, और expected behaviour या team के लिए सवाल लिखें।
  3. Defects को risk के क्रम में रखें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Method के हिसाब से safe और idempotent: दोनों GET lines, हालाँकि coupon वाली line state बदलने का काम बताती है (b देखें)। Idempotent पर safe नहीं: PUT और DELETE। दोनों में से कोई नहीं: POST, और आम तौर पर PATCH।

a) Defect। PUT state set करता है, इसलिए दो एक जैसी requests के बाद quantity 2 रहनी चाहिए; यह server set करने की बजाय जोड़ देता है।

b) Design defect। Coupon लगाना state बदलता है, इसलिए यह GET के पीछे नहीं होना चाहिए, जहाँ crawlers, link previews और prefetching इसे चला सकते हैं। Expected: POST /v1/cart/coupons जैसा unsafe method। तब भी, वही code दो बार लगाने पर discount दोगुना नहीं होना चाहिए, जब तक coupon के नियम इसकी अनुमति न दें।

c) Defect। HEAD response में body नहीं होनी चाहिए, और उसके headers GET वाले headers से मेल खाने चाहिए।

d) Defect। Expected: supported methods बताने वाले Allow header के साथ 405 Method Not Allowed, server error नहीं।

e) Defect। PATCH को सिर्फ़ भेजे गए fields बदलने चाहिए; e-mail मिट जाना data loss है, और user अपने account से बाहर हो सकता है।

f) ज़रूरी नहीं कि defect हो, क्योंकि POST idempotent नहीं है। पूछें कि क्या client को POST retry करना भी चाहिए और क्या मौजूदा SKU दोबारा जोड़ने पर quantities merge होनी चाहिए, फिर तय हुआ नियम टेस्ट करें।

Risk का क्रम: e (data loss), b (automated tools से लगने वाले discounts), a (गलत quantities और totals), फिर d और c; f तब तक खुला रहेगा जब तक team जवाब न दे।

अक्सर पूछे जाने वाले सवाल

PUT और PATCH में क्या फ़र्क है?

PUT resource की पूरी नई state भेजता है और जो है उसे replace करता है, या नया बनाता है। PATCH सिर्फ़ बदलावों का विवरण भेजता है, जैसे एक field की नई value। वही PUT दो बार भेजने पर state हमेशा वही रहती है; PATCH आम तौर पर idempotent नहीं, क्योंकि "quantity में 1 जोड़ो" जैसा बदलाव जुड़ता जाता है।

क्या GET request में body हो सकती है?

HTTP message framing इसकी अनुमति देता है, लेकिन RFC 9110 कहता है कि GET के content का कोई सामान्य तय अर्थ नहीं, वह request का अर्थ नहीं बदल सकता, और कुछ servers ऐसी request reject कर सकते हैं। GET के inputs URI में रखें, जैसा path और query parameters वाला अगला lesson दिखाता है, या जब search को बड़ी structured body चाहिए तो POST इस्तेमाल करें।

क्या POST सिर्फ़ resources बनाने के लिए है?

नहीं। POST resource से content को उसके अपने नियमों से process करने को कहता है: item बनाना, form submit करना, job शुरू करना या complex search चलाना। Location के साथ 201 Created तभी अपेक्षित है जब कोई resource बने; वरना contract में लिखे अनुसार 200, 202 या 204।

DevTools में ऐसी OPTIONS requests क्यों दिखती हैं जो किसी ने नहीं लिखीं?

Browsers इन्हें CORS preflight के रूप में भेजते हैं: कुछ cross-origin requests से पहले, जैसे PUT, DELETE या custom headers वाली request, browser server से पूछता है कि असली request की अनुमति है या नहीं। Preflight fail हो तो असली request भेजी ही नहीं जाती। CORS वाला lesson इसे विस्तार से समझाता है।

संदर्भ

  • RFC 9110: HTTP SemanticsIETF · 2022HTTP मेथड, हेडर फ़ील्ड, स्टेटस कोड और कंटेंट निगोशिएशन के अर्थ, वायर वर्ज़न से स्वतंत्र।
  • RFC 5789: PATCH Method for HTTPIETF · 2010आंशिक अपडेट के लिए PATCH मेथड, जबकि PUT पूरे रिसोर्स को बदल देता है।
  • HTTP request methods — MDNMDN Web Docs (Mozilla)HTTP request methods (GET, POST, PUT, PATCH, DELETE आदि) और उनमें कौन-से safe, idempotent और cacheable हैं।
  • OWASP API Security Top 10 (2023)OWASP Foundation · 2023API की दस सबसे आम कमज़ोरियाँ: ऑब्जेक्ट-लेवल ऑथराइज़ेशन का टूटना, ऑथेंटिकेशन का टूटना, अनियंत्रित रिसोर्स खपत और अन्य।
टूल्स

Mutqan tools से अभ्यास करें

API रिक्वेस्ट बिल्डर

HTTP रिक्वेस्ट (method, URL, हेडर, auth, बॉडी) बनाएँ और भेजें, फिर रिस्पॉन्स जाँचें — आपके ब्राउज़र में हल्का-फुल्का Postman।

API टेस्टिंग

REST API टेस्टर

method, हेडर और JSON बॉडी पर पूरे नियंत्रण के साथ REST endpoint टेस्ट करें, फिर स्टेटस, हेडर और JSON path पर assertion लगाएँ।

API टेस्टिंग

cURL जनरेटर

मेथड, URL, हेडर, बॉडी और auth विकल्पों से cURL कमांड बनाएँ।

वेब

HTTP स्टेटस कोड लुकअप

किसी भी HTTP स्टेटस कोड का अर्थ, RFC संदर्भ और उसे कब इस्तेमाल करना है — सब एक जगह देखें।

वेब

और गहराई से

इस topic में आपकी प्रगति

QA रोडमैप का हिस्सा