HTTP GET ඉල්ලීමකදී , පරාමිතීන් විමසුම් නූලක් ලෙස යවනු ලැබේ :

http://example.com/page ? පරාමිතිය = අගය සහ තවත් =

HTTP POST ඉල්ලීමකදී , පරාමිතීන් URI සමඟ යවනු නොලැබේ.

සාරධර්ම කොහෙද? ඉල්ලීම් ශීර්ෂය තුළ? ඉල්ලීම් මණ්ඩලයේද? ඒක මොන වගේද?

අගයන් ඉල්ලීම් ශරීරය තුළ, අන්තර්ගත වර්ගය නියම කරන ආකෘතියට යවනු ලැබේ.

සාමාන්‍යයෙන් අන්තර්ගතයේ වර්ගය application/x-www-form-urlencoded, එබැවින් ඉල්ලීම් ආයතනය විමසුම් නූලට සමාන ආකෘතියක් භාවිතා කරයි:

parameter=value&also=another

ඔබ පෝරමයේ ගොනු උඩුගත කිරීමක් භාවිතා කරන විට, ඔබ multipart/form-dataඒ වෙනුවට කේතන ක්‍රමය භාවිතා කරයි, එය වෙනස් ආකෘතියක් ඇත. එය වඩාත් සංකීර්ණයි, නමුත් සාමාන්‍යයෙන් ඔබට එය පෙනෙන්නේ කුමක් දැයි සැලකිලිමත් වීමට අවශ්‍ය නැත, එබැවින් මම උදාහරණයක් පෙන්වන්නේ නැත, නමුත් එය පවතින බව දැන ගැනීම හොඳ විය හැකිය.

අන්තර්ගතය HTTP ශීර්ෂයන්ට පසුව තබා ඇත. HTTP POST හි ආකෘතිය වන්නේ HTTP ශීර්ෂයන් තිබීම, ඉන්පසු හිස් පේළියක් සහ ඉල්ලීම් ආයතනයයි. POST විචල්‍යයන් ශරීරයේ යතුරු අගය යුගල ලෙස ගබඩා කර ඇත.

පහත දැක්වෙන HTTP පෝස්ට් එකක අමු අන්තර්ගතයෙන් ඔබට මෙය දැකිය හැකිය:

POST /path/script.cgi HTTP/1.0
From: frog@jmarshall.com
User-Agent: HTTPTool/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 32

home=Cosby&favorite+flavor=flies

ඔබට මෙය ෆිද්ලර් වැනි මෙවලමක් භාවිතයෙන් දැක ගත හැකිය , එමඟින් අමු HTTP ඉල්ලීම සහ ප්‍රතිචාර ගෙවීම් කම්බි හරහා යවනු ලැබේ.

කෙටි පිළිතුර: POST ඉල්ලීම් වලදී, ඉල්ලීම්වල "ශරීරය" තුළ අගයන් යවනු ලැබේ. වෙබ් පෝරම සමඟ ඒවා බොහෝ විට යවනු ලබන්නේ මාධ්‍ය වර්ගයක application/x-www-form-urlencodedහෝ multipart/form-data. හසුරුව වෙබ් ඉල්ලීම් කිරීමට නිර්මාණය කර ඇති පරිගණක භාෂාව හෝ රාමුව සාමාන්යයෙන් එවැනි ඉල්ලීම් සමග "හරි දේ ™" කරන්න සහ පහසුවෙන් විකේත තළ අගයන් (වගේ වෙත පිවිසීම සඳහා ඔබට ලබා $_REQUESTහෝ $_POSTPHP හි, හෝ cgi.FieldStorage(), flask.request.formPython දී).

දැන් අපි ටිකක් දුරස් වෙමු, එය වෙනස තේරුම් ගැනීමට උපකාරී වේ;)

අතර වෙනස GETසහ POSTඉල්ලීම් බොහෝ දුරට ඍජු ඉල්ලීම් වේ. ඒවා ද වෙනස් ලෙස "භාවිතා" කරනු ලැබේ, එමඟින් සාරධර්ම සම්මත වන ආකාරයෙහි වෙනස පැහැදිලි කරයි.

GET ( අදාළ RFC අංශය )

GETඉල්ලීමක් ක්‍රියාත්මක කිරීමේදී , ඔබ සේවාදායකයාගෙන් එකක් හෝ ආයතන සමූහයක් ඉල්ලයි. ප්‍රති result ලය පෙරීමට සේවාදායකයාට ඉඩ දීම සඳහා, එය URL හි ඊනියා "විමසුම් නූල" භාවිතා කළ හැකිය. විමසුම් දාමය යනු පසු කොටසයි ?. මෙය යූආර්අයි සින්ටැක්ස් හි කොටසකි .

එබැවින්, ඔබගේ යෙදුම් කේතයේ දෘෂ්ටි කෝණයෙන් ( ඉල්ලීම ලැබෙන කොටස ), මෙම අගයන් වෙත ප්‍රවේශය ලබා ගැනීම සඳහා ඔබ යූආර්අයි විමසුම් කොටස පරීක්ෂා කළ යුතුය.

යතුරු සහ අගයන් URI හි කොටසක් බව සලකන්න. බ්‍රව්සර් යූආර්අයි දිගට සීමාවක් පැනවිය හැකිය . HTTP ප්‍රමිතියේ සඳහන් වන්නේ සීමාවක් නොමැති බවයි. නමුත් මේ ලියන අවස්ථාව වන විට, බොහෝ වෙබ් බ්රව්සර් කරන්න ඇති URIs (මම විශේෂිත වටිනාකම් නැහැ), සීමා. සේවාදායකයට නව තොරතුරු ඉදිරිපත් කිරීමට GETඉල්ලීම් කිසි විටෙකත් භාවිතා නොකළ යුතුය. විශේෂයෙන් විශාල ලේඛන නොවේ. ඔබ භාවිතා කළ යුතු එය කරයි POSTහෝ PUT.

POST ( අදාළ RFC අංශය )

POSTඉල්ලීමක් ක්‍රියාත්මක කිරීමේදී , සේවාදායකයා ඇත්ත වශයෙන්ම දුරස්ථ ධාරකයට නව ලේඛනයක් ඉදිරිපත් කරයි . එබැවින්, විමසුම් දාමයක් (අර්ථාන්විතව) තේරුමක් නැත. ඔබගේ යෙදුම් කේතය තුළ ඔබට ඒවාට ප්‍රවේශය නොමැති වන්නේ එබැවිනි.

POSTටිකක් වඩාත් සංකීර්ණ (සහ ය ක්රමයක් වඩාත් නම්යශීලී):

POST ඉල්ලීමක් ලැබෙන විට, ඔබ සැමවිටම "ගෙවීමක්" අපේක්ෂා කළ යුතුය, නැතහොත්, HTTP පද වලින්: පණිවිඩ ආයතනයක් . ප්‍රමිතියක් නොමැති නිසා (මට කිව හැකි තාක් දුරට, යෙදුම / ඔක්ටේට්-ප්‍රවාහය?) ආකෘතියක් නොමැති බැවින් පණිවුඩ ශරීරයම නිෂ් less ල ය. ශරීර ආකෘතිය Content-Typeශීර්ෂකය මගින් අර්ථ දක්වා ඇත . FORMසමඟ HTML අංගයක් භාවිතා කරන විට method="POST", මෙය සාමාන්‍යයෙන් application/x-www-form-urlencodedවේ. තවත් ඉතා සුලභ වර්ගයක් වන්නේ ඔබ ගොනු උඩුගත කිරීම් භාවිතා කරන්නේ නම් බහුපාර්ට් / පෝරම-දත්ත ය . නමුත් එය කළ හැකි දෙයක් දක්වා වූ, text/plain, අධික application/jsonහෝ චාරිත්රයක් application/octet-stream.

ඕනෑම අවස්ථාවක, යෙදුම විසින් හැසිරවිය නොහැකි POSTඉල්ලීමක් කළහොත් Content-Type, එය 415තත්ව කේතයක් ලබා දිය යුතුය .

බොහෝ ක්‍රමලේඛන භාෂා (සහ / හෝ වෙබ් රාමු) පණිවිඩ ශරීරය / සිට වඩාත් පොදු වර්ග දක්වා (වැනි application/x-www-form-urlencoded, multipart/form-dataහෝ application/json) අක්‍රීය කිරීමට / කේතනය කිරීමට ක්‍රමයක් ඉදිරිපත් කරයි . එබැවින් එය පහසුය. අභිරුචි වර්ග සඳහා තව ටිකක් වැඩ අවශ්‍ය වේ.

නිදසුනක් ලෙස සම්මත HTML පෝරම කේතනය කළ ලේඛනයක් භාවිතා කරමින්, යෙදුම පහත පියවරයන් අනුගමනය කළ යුතුය:

1. මේ බලන්න Content-Typeක්ෂේත්රයේ
2. අගය සහය දක්වන මාධ්‍ය වර්ග වලින් එකක් නොවේ නම්, 415තත්ව කේතයක් සමඟ ප්‍රතිචාරයක් ලබා දෙන්න
3. එසේ නොමැතිනම්, පණිවිඩ ශරීරයෙන් අගයන් විකේතනය කරන්න.

නැවතත්, PHP වැනි භාෂා හෝ වෙනත් ජනප්‍රිය භාෂාවන් සඳහා වෙබ් රාමු ඔබ වෙනුවෙන් මෙය හසුරුවනු ඇත. මෙයට ව්‍යතිරේකය වන්නේ 415දෝෂයයි. ඔබගේ යෙදුම සහාය දැක්වීමට සහ / හෝ සහාය නොදක්වන්නේ කුමන අන්තර්ගත වර්ගදැයි පුරෝකථනය කිරීමට කිසිදු රාමුවකට නොහැකිය. මෙය ඔබට භාරයි.

PUT ( අදාළ RFC අංශය )

ඒ PUTඉල්ලීම එච්චරමයි ලෙස හරියටම සමාන ආකාරයකින් සිදු කෙරේ POSTඉල්ලීමක්. විශාල වෙනස වන්නේ POSTඉල්ලීමක් මඟින් නව සම්පතක් නිර්මාණය කරන්නේ කෙසේද යන්න තීරණය කිරීමට සේවාදායකයාට ඉඩ දීමයි. Ically තිහාසිකව (දැන් යල්පැන ඇති RFC2616 සිට ඉල්ලීම යවන ලද URI හි "යටත්" (ළමා) ලෙස නව සම්පතක් නිර්මාණය කිරීම විය).

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

ප්‍රති consequ ලයක් ලෙස, පවතින සම්පතක් ප්‍රතිස්ථාපනය කිරීම සඳහා POSTඉල්ලීමක් සාමාන්‍යයෙන් භාවිතා නොවේ . ඒ ඉල්ලීම මේ දෙකම කරන්නේ නිර්මාණය කළ හැකි හා වෙනුවට.PUT

පැති සටහන

දුරස්ථයට අතිරේක දත්ත යැවීම සඳහා භාවිතා කළ හැකි " මාර්ග පරාමිතීන් " ද ඇත, නමුත් ඒවා ඉතා සුලභ ය, මම මෙහි වැඩි විස්තරයකට නොයමි. එහෙත්, යොමු කිරීම සඳහා, මෙන්න RFC වෙතින් උපුටා ගැනීමකි:

ධූරාවලි මාවත්වල තිත්-කොටස් හැරුණු විට, සාමාන්‍ය සින්ටැක්ස් මගින් මාර්ග ඛණ්ඩයක් පාරාන්ධ ලෙස සැලකේ. යූආර්අයි නිපදවන යෙදුම් බොහෝ විට යෝජනා ක්‍රමයට විශේෂිත වූ හෝ විරූපණය-හසුරුවන-විශේෂිත උප සං on ටක සීමා කිරීම සඳහා කොටසක ඉඩ දී ඇති වෙන් කළ අක්ෂර භාවිතා කරයි. නිදසුනක් ලෙස, අර්ධ අංශ (";") සහ සමාන ("=") වෙන් කර ඇති අක්ෂර බොහෝ විට එම කොටසට අදාළ වන පරාමිති සහ පරාමිති අගයන් සීමා කිරීමට භාවිතා කරයි. කොමාව (",") වෙන් කර ඇති අක්‍ෂරය බොහෝ විට සමාන අරමුණු සඳහා භාවිතා කරයි. උදාහරණයක් ලෙස, එක් යූආර්අයි නිෂ්පාදකයෙක් "නම" හි 1.1 අනුවාදය වෙත යොමු දැක්වීමට "නම; v = 1.1" වැනි කොටසක් භාවිතා කළ හැකි අතර තවත් අයෙකු "නම, 1.1" වැනි කොටසක් භාවිතා කිරීමට භාවිතා කරයි. පරාමිති වර්ග යෝජනා ක්‍රම-විශේෂිත අර්ථ නිරූපණයන් මගින් අර්ථ දැක්විය හැකිය,

ඔබට එය බ්‍රව්සර් URL තීරුවේ කෙලින්ම ටයිප් කළ නොහැක.

උදාහරණයක් ලෙස සජීවී HTTP ශීර්ෂ සමඟ අන්තර්ජාලය තුළ POST දත්ත යවන ආකාරය ඔබට දැක ගත හැකිය . ප්‍රති ult ලය එවැනි දෙයක් වනු ඇත

http://127.0.0.1/pass.php
POST /pass.php HTTP/1.1

Host: 127.0.0.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Referer: http://127.0.0.1/pass.php
Cookie: passx=87e8af376bc9d9bfec2c7c0193e6af70; PHPSESSID=l9hk7mfh0ppqecg8gialak6gt5
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
username=zurfyx&pass=password

එය පවසන තැන

Content-Length: 30
    username=zurfyx&pass=password

පශ්චාත් අගයන් වනු ඇත.

POST ඉල්ලීමක පෙරනිමි මාධ්‍ය වර්ගය වේ application/x-www-form-urlencoded. මෙය යතුරු අගය යුගල කේතනය කිරීමේ ආකෘතියකි. යතුරු අනුපිටපත් කළ හැකිය. සෑම යතුරු අගය යුගලයක්ම &අක්‍ෂරයකින් වෙන් කර ඇති අතර සෑම යතුරක්ම එහි වටිනාකමෙන් =අක්ෂරයකින් වෙන් කරනු ලැබේ .

උදාහරණයක් වශයෙන්:

Name: John Smith
Grade: 19

කේතනය කර ඇත්තේ:

Name=John+Smith&Grade=19

මෙය HTTP ශීර්ෂයන්ට පසුව ඉල්ලීම් ශරීරයේ තබා ඇත.

සමහර වෙබ් සේවා ඔබට ඉල්ලීම් දත්ත සහ පාර-දත්ත වෙන වෙනම තැබීමට අවශ්‍ය වේ . උදාහරණයක් ලෙස දුරස්ථ ශ්‍රිතයක් මඟින් අත්සන් කරන ලද පාර-දත්ත නූල යූආර්අයි හි ඇතුළත් කර ඇතැයි අපේක්ෂා කළ හැකි අතර දත්ත එච්ටීටීපී-ශරීරයක පළ කරනු ලැබේ.

POST ඉල්ලීම අර්ථ නිරූපණය ලෙස පෙනේ:

POST /?AuthId=YOURKEY&Action=WebServiceAction&Signature=rcLXfkPldrYm04 HTTP/1.1
Content-Type: text/tab-separated-values; charset=iso-8859-1
Content-Length: []
Host: webservices.domain.com
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: identity
User-Agent: Mozilla/3.0 (compatible; Indy Library)

name    id
John    G12N
Sarah   J87M
Bob     N33Y

මෙම ප්‍රවේශය Content-Typeවෙබ් සේවාදායකයක් සඳහා “විග්‍රහ කිරීමේ උපදෙස්” එකක් භාවිතා කරමින් QueryString සහ Body-Post තාර්කිකව ඒකාබද්ධ කරයි .

කරුණාකර සටහන් කරන්න: HTTP / 1.1 වම් පසින් (අවකාශය) සහ දකුණු පසින් (රේඛීය සංග්‍රහය) ඔතා ඇත .#32#10

HTTP POSTs හි ආකෘති අගයන් ඉල්ලීම් ශරීරය තුළට යවනු ලැබේ.

වැඩි විස්තර සඳහා පිරිවිතර බලන්න .

පළමුවෙන්ම, GETසහ අතර වෙනස හඳුනා ගනිමුPOST

ලබා ගන්න: එය ප්රකෘතිය වේ HTTPසේවාදායකය වෙත ඉදිරිපත් කරන අතර පසුව එන බව සේවාදායකය හා විමසුම් string සිට දත්ත ලබා ගැනීමට භාවිතා කරයි, එම ඉල්ලීම් ?තුළ URIසුවිශේෂී සම්පත් ලබා ගැනීමට භාවිතා කරයි.

මෙය ආකෘතියයි

GET /someweb.asp?data=value HTTP/1.0

මෙන්න data=valueවිමසුම් නූල් අගය සම්මත කර ඇත.

POST: සේවාදායකයට ආරක්ෂිතව දත්ත යැවීමට එය භාවිතා කරයි, එබැවින් අවශ්‍ය ඕනෑම දෙයක්, මෙය POSTඉල්ලීමක ආකෘතියයි

POST /somweb.aspHTTP/1.0
Host: localhost
Content-Type: application/x-www-form-urlencoded //you can put any format here
Content-Length: 11 //it depends
Name= somename

GET ඉක්මවා තැපැල් කරන්නේ ඇයි?

දී GETඇති සේවාදායක සාමාන්යයෙන් විමසුම string පාදක URL එක වෙත ඇත්තා වූ ද, වී යවන වටිනාකම, දැන් මේ 2 ප්රතිවිපාක තියෙනවා

• මෙම GETඉල්ලීම් පරාමිතීන් හා සමග බ්රවුසරයේ ඉතිහාසය සුරැකෙයි. එබැවින් ඔබගේ මුරපද බ්‍රව්සර් ඉතිහාසයේ සංකේතනය කර නොමැත. මෙය අතීතයේ දී ෆේස්බුක් සඳහා සැබෑ ගැටළුවක් විය.
• සාමාන්‍යයෙන් සේවාදායකයන්ට කොපමණ කාලයක් URIපැවතිය හැකිද යන්නට සීමාවක් ඇත. බොහෝ පරාමිතීන් යවා ඇත්නම් ඔබට ලැබෙනු ඇත414 Error - URI too long

තැපැල් ඉල්ලීමකදී ක්ෂේත්‍ර වලින් ඔබේ දත්ත ඒ වෙනුවට ශරීරයට එකතු වේ. ඉල්ලීම් පරාමිතීන්ගේ දිග ගණනය කරනු ලබන අතර අන්තර්ගතයේ දිග සඳහා ශීර්ෂයට එකතු කරනු ලබන අතර වැදගත් දත්ත කිසිවක් URL වෙත සෘජුවම එකතු නොවේ.

සේවාදායකයින්ට ඉල්ලීම් කරන්නේ කෙසේද යන්න පිළිබඳ මූලික තොරතුරු බැලීමට ඔබට ගූගල් සංවර්ධක මෙවලම් ජාල අංශය භාවිතා කළ හැකිය.

ඔබ නිතරම වැඩි වටිනාකම් ඔබේ එක් කළ හැකිය Request Headersවැනි Cache-Control, Origin, Accept.