POST සහ PUT HTTP ඉල්ලීමක් අතර වෙනස කුමක්ද?

ඔවුන් දෙදෙනාම ශරීරය තුළ ඇති සේවාදායකයට දත්ත යවන බවක් පෙනේ, එබැවින් ඒවා වෙනස් වන්නේ කුමක් ද?

HTTP PUT:

PUT ගොනුවක් හෝ සම්පතක් නිශ්චිත URI එකක තබයි, හරියටම එම URI හි. එම යූආර්අයි හි දැනටමත් ගොනුවක් හෝ සම්පතක් තිබේ නම්, PUT එම ගොනුව හෝ සම්පත ප්‍රතිස්ථාපනය කරයි. එහි කිසිදු ගොනුවක් හෝ සම්පතක් නොමැති නම්, PUT එකක් නිර්මාණය කරයි. පත් කරයි idempotent , නමුත් විදුලි බිල දාන්න ප්රතිචාර cacheable නොවේ.

PUT සඳහා HTTP 1.1 RFC පිහිටීම

HTTP සටහන:

POST නිශ්චිත URI වෙත දත්ත යවන අතර එම URI හි ඇති සම්පත් ඉල්ලීම හැසිරවීමට අපේක්ෂා කරයි. මෙම අවස්ථාවේදී වෙබ් සේවාදායකයාට නිශ්චිත සම්පතේ සන්දර්භය තුළ දත්ත සමඟ කළ යුත්තේ කුමක්ද යන්න තීරණය කළ හැකිය. පශ්චාත් ක්රමය නොවන idempotent කෙසේ වෙතත් තැපැල් ප්රතිචාර, ය ඒ නිසා දිගු සේවාදායකය සුදුසු මතකය-පාලන සකසයි හා ශීර්ෂ කල් ඉකුත්වේ ලෙස cacheable.

නිල HTTP RFC විසින් POST විය යුත්තේ:

• පවත්නා සම්පත් විවරණය කිරීම;
• දැන්වීම් පුවරුවකට, ප්‍රවෘත්ති සමූහයකට, තැපැල් ලැයිස්තුවකට හෝ ඒ හා සමාන ලිපි සමූහයකට පණිවිඩයක් පළ කිරීම;
• පෝරමයක් ඉදිරිපත් කිරීමේ ප්‍රති result ලය වැනි දත්ත සමූහයක් දත්ත හැසිරවීමේ ක්‍රියාවලියකට සැපයීම;
• උපග්‍රන්ථ මෙහෙයුමක් හරහා දත්ත සමුදායක් පුළුල් කිරීම.

POST සඳහා HTTP 1.1 RFC පිහිටීම

POST සහ PUT අතර වෙනස:

RFC විසින්ම මූලික වෙනස පැහැදිලි කරයි:

POST සහ PUT ඉල්ලීම් අතර ඇති මූලික වෙනස ඉල්ලීම- URI හි විවිධ අර්ථයන්ගෙන් පිළිබිඹු වේ. POST ඉල්ලීමක ඇති URI විසින් සංවෘත ආයතනය හැසිරවිය හැකි සම්පත හඳුනා ගනී. එම සම්පත දත්ත පිළිගැනීමේ ක්‍රියාවලියක්, වෙනත් ප්‍රොටෝකෝලයක් සඳහා දොරටුව හෝ ව්‍යාඛ්‍යාව පිළිගන්නා වෙනම ආයතනයක් විය හැකිය. ඊට හාත්පසින්ම වෙනස්ව, PUT ඉල්ලීමක ඇති URI විසින් ඉල්ලීම සමඟ බැඳී ඇති ආයතනය හඳුනා ගනී - පරිශීලක නියෝජිතයා URI අදහස් කරන්නේ කුමක්දැයි දන්නා අතර සේවාදායකයා එම ඉල්ලීම වෙනත් සම්පතකට යෙදවීමට උත්සාහ නොකළ යුතුය. ඉල්ලීම වෙනත් යූආර්අයි වෙත යොමුවීමට සේවාදායකයා කැමති නම්, එය 301 (ස්ථිරවම ගෙන යන) ප්‍රතිචාරයක් යැවිය යුතුය; පරිශීලක නියෝජිතයා පසුව ඉල්ලීම හරවා යැවිය යුතුද නැද්ද යන්න පිළිබඳව තමන්ගේම තීරණයක් ගනී.

මීට අමතරව, සහ වඩාත් සංක්ෂිප්තව, RFC 7231 වගන්තිය 4.3.4 PUT හි සඳහන් වේ (අවධාරණය එකතු කරන ලදි),

4.3.4. පුට්

PUT ක්‍රමය ඉල්ලා සිටින්නේ ඉලක්කගත සම්පතේ තත්වය createdහෝ replacedඉල්ලීම් පණිවිඩ ගෙවීම්වල ඇතුළත් කර ඇති නිරූපණය මගින් අර්ථ දක්වා ඇති තත්වය සමඟ ය.

නිවැරදි ක්‍රමය භාවිතා කිරීම, සම්බන්ධයක් පසෙකට දමා:

REST ROA එදිරිව SOAP හි එක් වාසියක් වන්නේ HTTP REST ROA භාවිතා කරන විට, එය HTTP ක්‍රියාපද / ක්‍රම නිසි ලෙස භාවිතා කිරීම දිරිමත් කිරීමයි. උදාහරණයක් ලෙස ඔබ PUT භාවිතා කරන්නේ ඔබට එම ස්ථානයේම සම්පතක් නිර්මාණය කිරීමට අවශ්‍ය වූ විට පමණි. සම්පතක් නිර්මාණය කිරීමට හෝ වෙනස් කිරීමට ඔබ කිසි විටෙකත් GET භාවිතා නොකරනු ඇත.

අර්ථ නිරූපණය පමණි.

HTTP PUTවිසින් ඉල්ලීම පිළිගත යුතු අතර, එය URI විසින් හඳුනාගත් සම්පතෙහි ගබඩා කරයි.

HTTP POSTවඩාත් පොදු වේ. එය සේවාදායකයේ ක්‍රියාවක් ආරම්භ කිරීමට නියමිතය. එම ක්‍රියාව විය හැක්කේ ඉල්ලීම් ආයතනය යූආර්අයි විසින් හඳුනාගත් සම්පතෙහි ගබඩා කිරීම හෝ එය වෙනත් යූආර්අයි එකක් විය හැකිය, නැතහොත් එය වෙනස් ක්‍රියාවක් විය හැකිය.

PUT යනු ගොනු උඩුගත කිරීමක් වැනිය . යූආර්අයි එකකට දැමීම හරියටම එම යූආර්අයි වලට බලපායි. යූආර්අයි වෙත තැපැල් කිරීම කිසියම් බලපෑමක් ඇති කළ හැකිය.

REST විලාසිතාවේ සම්පත් සඳහා උදාහරණ ලබා දීමට:

පොත් තොරතුරු පොකුරක් සහිත "POST / books" මඟින් නව පොතක් නිර්මාණය කළ හැකි අතර, එම පොත හඳුනාගන්නා නව URL සමඟ ප්‍රතිචාර දක්වන්න: "/ books / 5".

"PUT / books / 5" ට 5 හි හැඳුනුම්පත සමඟ නව පොතක් සෑදිය යුතුය, නැතහොත් පවතින පොත ID 5 සමඟ ප්‍රතිස්ථාපනය කළ යුතුය.

සම්පත් නොවන ශෛලිය තුළ, අතුරු ආබාධ ඇති ඕනෑම දෙයක් සඳහා POST භාවිතා කළ හැකිය. තවත් එක් වෙනසක් නම්, PUT අනර්ථකාරී විය යුතුය - එකම URL එකකට එකම දත්තවල බහු PUT හොඳ විය යුතුය, බහු POSTs බහු වස්තු නිර්මාණය කළ හැකිය හෝ එය ඔබගේ POST ක්‍රියාව කුමක් වුවත්.

1. ලබා ගන්න : සේවාදායකයෙන් දත්ත ලබා ගනී. වෙනත් බලපෑමක් නොතිබිය යුතුය.
2. PUT : ඉල්ලුම් ගෙවීම් සමඟ ඉලක්ක සම්පත් ප්‍රතිස්ථාපනය කරයි. නව සම්පත් යාවත්කාලීන කිරීමට හෝ නිර්මාණය කිරීමට භාවිතා කළ හැකිය.
3. පැච් : PUT ට සමාන නමුත් පවතින සම්පතක් තුළ ඇතැම් ක්ෂේත්‍ර පමණක් යාවත්කාලීන කිරීමට භාවිතා කරයි.
4. POST : ගෙවීම් භාරය මත සම්පත් විශේෂිත සැකසුම් සිදු කරයි. නව සම්පතක් නිර්මාණය කිරීම, ගොනුවක් උඩුගත කිරීම හෝ වෙබ් පෝරමයක් ඉදිරිපත් කිරීම ඇතුළු විවිධ ක්‍රියා සඳහා භාවිතා කළ හැකිය.
5. Delete : සේවාදායකය වෙතින් ඉවත් කරයි දත්ත.
6. TRACE : සේවාදායකයාට ලැබෙන දේ පරීක්ෂා කිරීමට ක්‍රමයක් සපයයි. එය යවන ලද දේ ආපසු ලබා දෙයි.
7. විකල්ප : සේවාවක් මඟින් සහාය දක්වන ඉල්ලීම් ක්‍රම පිළිබඳ තොරතුරු ලබා ගැනීමට සේවාදායකයෙකුට ඉඩ දෙන්න. අදාළ ප්‍රතිචාර ශීර්ෂය වන්නේ සහාය දක්වන ක්‍රම සමඟ ඉඩ දෙන්න. සත්‍ය ඉල්ලීම් ක්‍රමය ගැන සේවාදායකයා දැනුවත් කිරීමට සහ අභිරුචි ශීර්ෂයන් ගැන විමසීමට පූර්ව ආලෝක ඉල්ලීමක් ලෙස CORS හි භාවිතා වේ.
8. හිස : ප්‍රතිචාර ශීර්ෂ පමණක් ලබා දෙයි.
9. සම්බන්ධතාවය : බ්‍රව්සරය එය ප්‍රොක්සියක් සමඟ කතා කරන බව දැනගත් විට භාවිතා කරන අතර අවසාන යූආර්අයි ආරම්භ වන්නේ https: // සමඟ ය. සම්බන්ධතාවයේ අභිප්‍රාය වන්නේ එන්ක්‍රිප්ට් කරන ලද ටීඑල්එස් සැසියට අවසානයට ඉඩ දීමයි, එබැවින් දත්ත ප්‍රොක්සියකට කියවිය නොහැක.

PUT යනු කිසියම් යූආර්අයි වෙත දේවල් "උඩුගත කිරීම" හෝ එම යූආර්අයි හි දැනටමත් ඇති දේ නැවත ලිවීම සඳහා වූ ක්‍රමවේදයකි.

POST, අනෙක් අතට, ලබා දී ඇති URI වෙත අදාළ දත්ත ඉදිරිපත් කිරීමේ ක්‍රමයකි.

HTTP RFC වෙත යොමු වන්න

මා දන්නා පරිදි, PUT වැඩිපුරම භාවිතා කරනුයේ වාර්තා යාවත්කාලීන කිරීම සඳහා ය.

1. POST - ලේඛනයක් හෝ වෙනත් සම්පතක් නිර්මාණය කිරීමට

2. PUT - සාදන ලද ලේඛනය හෝ වෙනත් සම්පතක් යාවත්කාලීන කිරීම.

නමුත් එම PUT හි පැහැදිලිව කිවහොත් සාමාන්‍යයෙන් පවතින වාර්තාව එහි තිබේ නම් එය ප්‍රතිස්ථාපනය කර එය නොමැති නම් නිර්මාණය කරයි.

අනෙක් අය දැනටමත් විශිෂ්ට පිළිතුරු පළ කර ඇති අතර, මට අවශ්‍ය වූයේ බොහෝ භාෂාවන්, රාමු සහ භාවිත අවස්ථා සමඟ ඔබ POST සමඟ ගනුදෙනු කරන අතර PUT ට වඩා බොහෝ විට ය. PUT, DELETE යනාදිය මූලික වශයෙන් සුළු ප්‍රශ්න වේ.

කරුණාකර බලන්න: http://zacharyvoase.com/2009/07/03/http-post-put-diff/

සම්පතක් නිර්මාණය කිරීම සඳහා POST භාවිතා කරන බවට වෙබ් සංවර්ධකයින්ගේ ජනප්‍රිය වැරදි වැටහීමක් නිසා මම මෑතකදී තරහට පත්ව සිටිමි. එකක් යාවත්කාලීන කිරීමට / වෙනස් කිරීමට PUT භාවිතා කරයි.

ඔබ RFC 2616 (“හයිපර් ටෙක්ස්ට් ට්‍රාන්ස්ෆර් ප්‍රොටොකෝලය - HTTP / 1.1”), 9.6 වගන්තිය (“PUT”) හි 55 වන පිටුව දෙස බැලුවහොත් , PUT සැබවින්ම කුමක් සඳහා දැයි ඔබට පෙනෙනු ඇත:

සපයන ලද ඉල්ලීම- URI යටතේ සංවෘත වස්තුව ගබඩා කරන ලෙස PUT ක්‍රමය ඉල්ලා සිටී.

POST සහ PUT අතර වෙනස පැහැදිලි කිරීම සඳහා පහසු ඡේදයක් ද ඇත:

POST සහ PUT ඉල්ලීම් අතර ඇති මූලික වෙනස ඉල්ලීම- URI හි විවිධ අර්ථයන්ගෙන් පිළිබිඹු වේ. POST ඉල්ලීමක ඇති URI විසින් සංවෘත ආයතනය හැසිරවිය හැකි සම්පත හඳුනා ගනී. එම සම්පත දත්ත පිළිගැනීමේ ක්‍රියාවලියක්, වෙනත් ප්‍රොටෝකෝලයක් සඳහා දොරටුව හෝ ව්‍යාඛ්‍යාව පිළිගන්නා වෙනම ආයතනයක් විය හැකිය. ඊට හාත්පසින්ම වෙනස්ව, PUT ඉල්ලීමක ඇති URI විසින් ඉල්ලීම සමඟ බැඳී ඇති ආයතනය හඳුනා ගනී - පරිශීලක නියෝජිතයා URI අදහස් කරන්නේ කුමක්දැයි දන්නා අතර සේවාදායකයා එම ඉල්ලීම වෙනත් සම්පතකට යෙදවීමට උත්සාහ නොකළ යුතුය.

යාවත්කාලීන කිරීම / නිර්මාණය කිරීම අතර වෙනස ගැන එහි කිසිවක් සඳහන් නොවේ, මන්ද එය ඒ ගැන නොවේ. එය මේ අතර ඇති වෙනස ගැන ය:

obj.set_attribute(value) # A POST request.

මෙය:

obj.attribute = value # A PUT request.

එබැවින් කරුණාකර, මෙම ජනප්‍රිය වැරදි වැටහීම පැතිරීම නවත්වන්න. ඔබේ RFCs කියවන්න.

POST කර්මාන්තශාලා වර්ගයේ ක්‍රමයක් ලෙස සැලකේ. ඔබට අවශ්‍ය දේ නිර්මාණය කිරීම සඳහා ඔබ එය සමඟ දත්ත ඇතුළත් කරන අතර අනෙක් කෙළවරේ ඇති ඕනෑම දෙයක් එය සමඟ කළ යුතු දේ දනී. ලබා දී ඇති URL එකක පවතින දත්ත යාවත්කාලීන කිරීමට හෝ යූආර්අයි යනු කුමක්දැයි ඔබ දන්නා විට එය අලුත් දෙයක් නිර්මාණය කිරීමට PUT භාවිතා කරයි (එය දැනටමත් නොපවතී) අවශ්‍ය නම් එය).

REST සංවර්ධකයින්ගෙන් HTTP ක්‍රම පැහැදිලිව හා ප්‍රොටොකෝලය අර්ථ දැක්වීමට අනුකූල වන ලෙස භාවිතා කරන ලෙස ඉල්ලා සිටී. මෙම මූලික REST සැලසුම් මූලධර්මය මඟින් නිර්මාණය කිරීම, කියවීම, යාවත්කාලීන කිරීම සහ මකා දැමීම (CRUD) මෙහෙයුම් සහ HTTP ක්‍රම අතර එකින් එක සිතියම් ගත කරයි. මෙම සිතියම්ගත කිරීම අනුව:

Server සේවාදායකයේ සම්පතක් නිර්මාණය කිරීමට, POST භාවිතා කරන්න.

Res සම්පතක් ලබා ගැනීමට, GET භාවිතා කරන්න.

Res සම්පතක තත්වය වෙනස් කිරීමට හෝ එය යාවත්කාලීන කිරීමට, PUT භාවිතා කරන්න.

Resource සම්පතක් ඉවත් කිරීමට හෝ මකා දැමීමට, මකන්න.

වැඩි විස්තර: RESTful වෙබ් සේවා: IBM වෙතින් මූලික කරුණු

එකක් හෝ වෙනත් එකක් භාවිතා කරන විට එය ඉතා සරල විය යුතුය, නමුත් සංකීර්ණ වචන අප බොහෝ දෙනෙකුට ව්‍යාකූලත්වයට හේතු වේ.

ඒවා භාවිතා කළ යුත්තේ කවදාද:

• PUTදැනටමත් සම්පත් එකතු කිරීමේ කොටසක් වන ඒකීය සම්පතක් වෙනස් කිරීමට ඔබට අවශ්‍ය විට භාවිතා කරන්න . PUTසම්පත සම්පූර්ණයෙන්ම ප්‍රතිස්ථාපනය කරයි. උදාහරණයක්:PUT /resources/:resourceId

  Sidenote:PATCH ඔබට සම්පතේ කොටසක් යාවත්කාලීන කිරීමට අවශ්‍ය නම් භාවිතා කරන්න .

• POSTසම්පත් එකතුවක් යටතේ ළමා සම්පතක් එක් කිරීමට ඔබට අවශ්‍ය විට භාවිතා කරන්න .
  උදාහරණයක්:POST => /resources

සාමාන්යයෙන්:

• සාමාන්යයෙන්, ප්රායෝගිකව, සෑම විටම යාවත්කාලීන මෙහෙයුම් PUTසඳහා භාවිතා කරන්න .
• CREATE මෙහෙයුම් POSTසඳහා සැමවිටම භාවිතා කරන්න .

උදාහරණයක්:

GET / company / report => සියලුම වාර්තා ලබා ගන්න
GET / සමාගම / වාර්තා / {id} => "id"
POST / company / report විසින් හඳුනාගත් වාර්තා තොරතුරු ලබා ගන්න => නව වාර්තාවක් සාදන්න
PUT / සමාගම / වාර්තා / {id} => යාවත්කාලීන කරන්න "id" විසින් හඳුනාගත් වාර්තාව තොරතුරු
PATCH / සමාගමක් / වාර්තා / {id} => යාවත්කාලීන "id" මගින් හඳුනාගත් වාර්තාව තොරතුරු කොටසක්
DELETE / සමාගමක් / වාර්තා / {id} => මකන්න "id" වාර්තාව සඳහන් කරන ලද්දේ

POST සහ PUT අතර ඇති වෙනස නම්, PUT අනර්ථකාරී වීමයි, එයින් අදහස් වන්නේ එකම PUT ඉල්ලීම කිහිප වතාවක් ඇමතීමෙන් සෑම විටම එකම ප්‍රති result ලය ලැබෙනු ඇති බවයි (එය අතුරු ආබාධයක් නොවේ), අනෙක් අතට, POST ඉල්ලීමක් නැවත නැවත කැඳවීම ( අතිරේක) එකම සම්පතක් කිහිප වතාවක් නිර්මාණය කිරීමේ අතුරු ආබාධ.

GET : GET භාවිතා කර ඉල්ලීම් ලබා ගන්නේ දත්ත ලබා ගැනීම පමණි, එනම් එය නිශ්චිත සම්පතක් නිරූපණය කිරීම ඉල්ලා සිටී

POST: එය සම්පතක් නිර්මාණය කිරීම සඳහා සේවාදායකයට දත්ත යවයි. ඉල්ලීමේ ශරීරයේ වර්ගය අන්තර්ගත-වර්ගයේ ශීර්ෂයෙන් දැක්වේ. එය බොහෝ විට සේවාදායකයේ තත්වය හෝ අතුරු ආබාධ වෙනස් කිරීමට හේතු වේ

PUT : නව සම්පතක් නිර්මාණය කිරීම හෝ ඉලක්කගත සම්පත නියෝජනය කිරීම ඉල්ලීම් ගෙවීම් සමඟ ප්‍රතිස්ථාපනය කරයි

PATCH : සම්පතකට අර්ධ වෙනස් කිරීම් යෙදීම සඳහා එය භාවිතා කරයි

DELETE : එය නිශ්චිත සම්පත මකා දමයි

TRACE : එය ඉලක්කගත සම්පත කරා යන මාර්ගය ඔස්සේ පණිවුඩ ලූප්-බැක් පරීක්ෂණයක් සිදු කරයි, එය ප්‍රයෝජනවත් නිදොස් කිරීමේ යාන්ත්‍රණයක් සපයයි

OPTIONS : ඉලක්කගත සම්පත සඳහා සන්නිවේදන විකල්ප විස්තර කිරීමට එය භාවිතා කරයි, සේවාදායකයාට OPTIONS ක්‍රමය සඳහා URL එකක් හෝ සමස්ත සේවාදායකය වෙත යොමු කිරීම සඳහා තරු ලකුණු (*) නියම කළ හැකිය.

HEAD : එය GET ඉල්ලීමකට සමාන ප්‍රතිචාරයක් ඉල්ලා සිටින නමුත් ප්‍රතිචාර ආයතනයකින් තොරව

CONNECT : එය ඉලක්කගත සම්පත් මගින් හඳුනාගත් සේවාදායකයට උමගක් ස්ථාපිත කරයි, SSL (HTTPS) භාවිතා කරන වෙබ් අඩවි වලට ප්‍රවේශ වීමට භාවිතා කළ හැකිය.

REST- පූර්ණ භාවිතය

POST නව සම්පතක් නිර්මාණය කිරීමට භාවිතා කර සම්පත ආපසු ලබා දේ URI

EX 
      REQUEST : POST ..../books
        {
        "book":"booName",
        "author":"authorName"
        }

මෙම ඇමතුම මඟින් නව පොතක් නිර්මාණය කර එම පොත නැවත ලබා දෙනු ඇත URI

Response ...THE-NEW-RESOURCE-URI/books/5

PUT සම්පතක් ප්‍රතිස්ථාපනය කිරීමට භාවිතා කරයි, එම සම්පත තිබේ නම් එය යාවත්කාලීන කරන්න, නමුත් එම සම්පත නොපවතී නම් එය සාදන්න,

REQUEST : PUT ..../books/5
{
"book":"booName",
"author":"authorName"
}

PUTසම්පත් හඳුනාගැනීමේ යන්ත්‍රය අප දන්නා නමුත් POSTනව සම්පත් හඳුනාගැනුම නැවත ලබා දෙනු ඇත

REST- පූර්ණ නොවන භාවිතය

POST සේවාදායකයාගේ පැත්තෙන් ක්‍රියාවක් ආරම්භ කිරීමට භාවිතා කරයි, මෙම ක්‍රියාව සම්පතක් නිර්මාණය කිරීමට හෝ නොවීමට ඉඩ ඇත, නමුත් මෙම ක්‍රියාව පැත්තට බලපාන අතර එය සැමවිටම සේවාදායකයේ යමක් වෙනස් කරයි

PUT නිශ්චිත URL එකක වචනාර්ථමය අන්තර්ගතය ස්ථානගත කිරීමට හෝ ප්‍රතිස්ථාපනය කිරීමට භාවිතා කරයි

REST-ful සහ REST-ful නොවන විලාසිතාවන්හි තවත් වෙනසක්

POST පරමාදර්ශී නොවන මෙහෙයුම: එකම ඉල්ලීමකින් කිහිප වතාවක් ක්‍රියාත්මක කළ හොත් එය යම් යම් වෙනස්කම් ඇති කරයි.

PUT Idempotent Operation: එකම ඉල්ලීමකින් කිහිප වතාවක් ක්‍රියාත්මක කළහොත් එයට අතුරු ආබාධ ඇති නොවේ.

සරල වචන වලින් ඔබට මෙසේ පැවසිය හැකිය:

1.HTTP ලබා ගන්න: අයිතම එකක් හෝ කිහිපයක් ලබා ගැනීමට එය භාවිතා කරයි

2.HTTP පෝස්ට්: එය අයිතමයක් නිර්මාණය කිරීමට භාවිතා කරයි

3.HTTP put: එය අයිතමයක් යාවත්කාලීන කිරීමට භාවිතා කරයි

4.HTTP පැච්: අයිතමයක් අර්ධ වශයෙන් යාවත්කාලීන කිරීමට එය භාවිතා කරයි

5.HTTP මකන්න: එය අයිතමයක් මකා දැමීමට භාවිතා කරයි

එය වටිනා සඳහන් වූ වනු ඇත POSTසමහර පොදු යටත් වේ හරස් අඩවිය ඉල්ලීම් ව්යාජ අඩවියකි (CSRF) ප්රහාර එල්ල වන අතර PUTනැත.

වින්දිතයා බැලීමට යන විට පහත CSRF කළ නොහැකPUTattackersite.com .

මෙම ප්රහාරය ක්රියාත්මක වන බව ය ගොදුරක් නොසිතාම පරිශීලක දමයි එය (ගොදුරක්) ප්රවිෂ්ට වූ පමණින් ලෙස adminමත target.site.com, සංචාරය පෙර attackersite.com:

සාමාන්‍ය ඉල්ලීම (කුකීස් යවනු ලැබේ): ( PUTසහාය දක්වන ගුණාංගයක් නොවේ)

කේතය මත attackersite.com:

<form id="myform" method="post" action="http://target.site.com/deleteUser" >
    <input type="hidden" name="userId" value="5">
</form>
<script>document.createElement('form').submit.call(document.getElementById('myform'));</script>

XHR ඉල්ලීම (කුකීස් යවනු ලැබේ): ( PUTපූර්ව ආලෝක ඉල්ලීමක් අවුලුවන අතර, ප්‍රතිචාරය මඟින් බ්‍රව්සරය deleteUserපිටුව ඉල්ලීම වලක්වනු ඇත )

var xhr = new XMLHttpRequest();
xhr.open("POST", "http://target.site.com/deleteUser");
xhr.withCredentials=true;
xhr.send(["userId=5"]);

ඇත්තටම ඔවුන්ගේ මාතෘකාව හැර වෙනත් වෙනසක් නැත. GET සහ අනෙක් ඒවා අතර මූලික වෙනසක් ඇත. "GET" -Request ක්‍රමයක් සමඟ, ඔබ url-address-line හි දත්ත යවනු ලබන අතර, ඒවා පළමුව ප්‍රශ්නාර්ථ ලකුණකින් වෙන් කරනු ලැබේ, පසුව & ලකුණක් සමඟ.

නමුත් "POST" ඉල්ලීම් ක්‍රමයක් සමඟ, ඔබට url හරහා දත්ත යැවිය නොහැක, නමුත් ඉල්ලීමෙහි ඊනියා "ශරීරය" තුළ දත්ත වස්තුවක් ලෙස සම්මත කළ යුතුය. සේවාදායක පැත්තේ, එවූ දත්ත ලබා ගැනීම සඳහා ඔබට ලැබුණු අන්තර්ගතයේ සිරුර කියවිය යුතුය. නමුත් ඔබ "GET" ඉල්ලීමක් යවන විට අනෙක් පැත්තෙන් ශරීරයේ අන්තර්ගතය යැවීමට හැකියාවක් නැත.

"GET" යනු දත්ත ලබා ගැනීම සඳහා පමණක් වන අතර "POST" යනු දත්ත පළ කිරීම සඳහා වන බවට වන ප්‍රකාශය සම්පූර්ණයෙන්ම වැරදිය. "GET" ඉල්ලීම මගින් හෝ "POST" ඉල්ලීම මගින් යවනු ලබන දත්ත මත පදනම්ව නව අන්තර්ගතයන් නිර්මාණය කිරීම, පවතින අන්තර්ගතයන් මකා දැමීම, පවතින අන්තර්ගතයන් සංස්කරණය කිරීම හෝ පසුබිම තුළ ඕනෑම දෙයක් කිරීම කිසිවෙකුට වළක්වා ගත නොහැක. “POST” ඉල්ලීමක් සමඟ සේවාදායකයා යම් දත්තයක් ඉල්ලා සිටින ආකාරයට කිසිවෙකුට ඔබව පසුපසට කේත කිරීම වළක්වා ගත නොහැක.

ඉල්ලීමක් සමඟ, ඔබ කුමන ක්‍රමයක් භාවිතා කළත්, ඔබ URL එකක් අමතා නිශ්චිත දත්ත යැවීම හෝ යැවීම නොකරන්න, ඔබේ ඉල්ලීම සමඟ කටයුතු කිරීම සඳහා සේවාදායකයට යැවිය යුතු තොරතුරු මොනවාද, එවිට සේවාදායකයාට පිළිතුරක් ලැබේ සේවාදායකය. ඔබට යැවීමට අවශ්‍ය ඕනෑම දෙයක් දත්තවල අඩංගු විය හැකි අතර, දත්ත සමඟ අවශ්‍ය ඕනෑම දෙයක් කිරීමට පසුපසට අවසර දී ඇති අතර ප්‍රතිචාරයේ ඕනෑම තොරතුරක් අඩංගු විය හැකිය.

ඇත්තේ මෙම මූලික ක්‍රම දෙක පමණි. GET සහ POST. නමුත් එය ඔවුන්ගේ ව්‍යුහය වන අතර එමඟින් ඒවා වෙනස් වන අතර ඔබ පසුපෙළේ කේත කරන දේ නොවේ. ලැබුණු දත්ත සමඟ ඔබට අවශ්‍ය ඕනෑම දෙයක් කේතගත කළ හැකිය. නමුත් "POST" ඉල්ලීම සමඟ ඔබට යූආර්එල්-ලිපින රේඛාවේ නොව ශරීරයේ දත්ත යැවීමට / ලබා ගැනීමට සිදු වන අතර "GET" ඉල්ලීමක් සමඟ ඔබට url ලිපිනයෙහි දත්ත යැවීමට / ලබා ගැනීමට සිදු වේ. ශරීරය. එච්චරයි.

"PUT", "DELETE" වැනි අනෙකුත් සියලුම ක්‍රම වලට "POST" හා සමාන ව්‍යුහයක් ඇත.

POST ක්‍රමය ප්‍රධාන වශයෙන් භාවිතා කරනුයේ, ඔබට අන්තර්ගතය තරමක් සැඟවීමට අවශ්‍ය නම්, මන්ද ඔබ url ලිපින ලිපියේ ලියන ඕනෑම දෙයක් මෙය හැඹිලියේ සුරකිනු ඇති අතර GET-Method යනු දත්ත සමඟ url- ලිපින රේඛාවක් ලිවීමට සමාන වේ. එබැවින් ඔබට සෑම විටම අවශ්‍යයෙන්ම පරිශීලක නාමය සහ මුරපදය නොවන සංවේදී දත්ත යැවීමට අවශ්‍ය නම්, නමුත් උදාහරණයක් ලෙස url-address-line හි පෙන්වීමට ඔබට අවශ්‍ය නැති සමහර අයිඩී හෝ හැෂ්, ඔබ POST ක්‍රමය භාවිතා කළ යුතුය. .

URL- ලිපින රේඛාවේ දිග සංකේත 1024 කට සීමා වන අතර "POST" ක්‍රමය සීමා නොකෙරේ. එබැවින් ඔබට වඩා විශාල දත්ත ප්‍රමාණයක් තිබේ නම්, ඔබට එය GET- ඉල්ලීමක් සමඟ යැවීමට නොහැකි වනු ඇත, නමුත් ඔබට POST-Request භාවිතා කිරීමට අවශ්‍ය වනු ඇත. එබැවින් මෙය POST ඉල්ලීම සඳහා තවත් ප්ලස් පොයින්ට් එකකි.

ඔබට යැවීමට සංකීර්ණ පෙළ නොමැති විට, GET- ඉල්ලීම සමඟ කටයුතු කිරීම පහසුය. එසේ නොමැතිනම්, මෙය POST ක්‍රමයට තවත් ප්ලස් පොයින්ට් එකක් වේ, එනම්, GET- ක්‍රමය සමඟ ඔබට පෙළ හෝ අවකාශය තුළ පවා යම් සංකේත යැවීමට හැකිවන පරිදි, පෙළ url- කේතනය කළ යුතුය. නමුත් POST ක්‍රමයක් සමඟ ඔබට කිසිදු සීමාවක් නොමැති අතර ඔබේ අන්තර්ගතය කිසිදු ආකාරයකින් වෙනස් කිරීමට හෝ හැසිරවීමට අවශ්‍ය නොවේ.

PUT සහ POST යන දෙකම විවේක ක්‍රම වේ.

PUT - අපි දෙවරක් එකම පරාමිතීන් භාවිතා කරමින් PUT භාවිතා කරමින් එකම ඉල්ලීම දෙවරක් කළහොත්, දෙවන ඉල්ලීමට කිසිදු බලපෑමක් සිදු නොවේ. යාවත්කාලීන කිරීමේ අවස්ථාව සඳහා සාමාන්‍යයෙන් PUT භාවිතා කරනුයේ, එකම පරාමිතීන් සමඟ එක් වරකට වඩා වැඩි වාර ගණනක් ඇමතීම ආරම්භක ඇමතුමට වඩා වැඩි යමක් නොකරන නිසා PUT අනර්ථකාරී ය.

POST නිර්‍මාණවත් නොවේ, නිදසුනක් ලෙස Create මඟින් ඉලක්කයට වෙනම ඇතුළත් කිරීම් දෙකක් නිර්මාණය කරනු ඇත, එබැවින් එය නිෂ් id ල නොවේ, එබැවින් POST හි CREATE බහුලව භාවිතා වේ.

සෑම විටම එකම පරාමිතීන් සහිත POST භාවිතා කරමින් එකම ඇමතුමක් ලබා ගැනීම වෙනස් කරුණු දෙකක් සිදුවීමට හේතු වේ, එබැවින් නිර්මාණය කිරීමේ අවස්ථාව සඳහා POST බහුලව භාවිතා වන්නේ ඇයි?