HTML ආකෘති වල PUT සහ DELETE ක්‍රම නොමැති ඇයි?

HTML4 / XHTML1 මඟින් GET සහ POST ආකෘති වලට පමණක් ඉඩ දෙයි, දැන් HTML5 එයම කරයි. ඇත එකතු කිරීමට යෝජනාවක් මේ දෙක නමුත් එය, ගැම්ම ගනිමින් සිටින බව පෙනේ නැත. HTML5 පිරිවිතර කෙටුම්පතට PUT සහ DELETE ඇතුළත් නොකිරීමට තාක්ෂණික හෝ දේශපාලන හේතු මොනවාද?

මෙය සිත්ගන්නාසුලු ප්‍රශ්නයකි. මෙහි ඇති අනෙක් පිළිතුරු සියල්ලම සමපේක්ෂන වන අතර සමහර අවස්ථාවල පැතලි කිරීම වැරදිය. මගේ මතය මෙහි ලිවීම වෙනුවට, මම ඇත්ත වශයෙන්ම යම් පර්යේෂණයක් කළ අතර මකාදැමීම සහ දැමීම HTML5 ආකෘති ප්‍රමිතියේ කොටසක් නොවන්නේ මන්දැයි සාකච්ඡා කරන මුල් ප්‍රභවයන් සොයා ගතිමි .

එය දුටුවේ, මෙම ක්රම ලදී ඇතුළත් කිහිපයක් මුල් HTML5 කෙටුම්පත් (!), නමුත්, පසුව ඉවත් කරන ලදී පසුව කෙටුම්පත් . මොසිල්ලා ඇත්ත වශයෙන්ම මෙය ෆයර්ෆොක්ස් බීටා තුළ ද ක්‍රියාත්මක කර තිබේ.

මෙම ක්‍රම කෙටුම්පතෙන් ඉවත් කිරීම සඳහා වූ තර්කය කුමක්ද? W3C මෙම මාතෘකාව දෝෂ වාර්තාව 10671 හි සාකච්ඡා කළේය. මයික් අමුන්ඩ්සන් මෙම සහයෝගයට පක්ෂව තර්ක කළේය:

මූල සේවාදායකයේ සම්පත් වෙනස් කිරීම සඳහා PUT සහ DELETE ක්‍රියාත්මක කිරීම XmlHttpRequest වස්තුව භාවිතා කරන නවීන වෙබ් බ්‍රව්සර් සඳහා කෙළින්ම ඉදිරියට යයි. ලේඛනගත නොකළ බ්‍රව්සර් අන්තර්ක්‍රියා සඳහා මෙය එතරම් සරල නැත. [...]

මෙම රටාව බොහෝ විට අවශ්‍ය වන්නේ බහුලව භාවිතා වන වෙබ් රාමු / පුස්තකාල කිහිපයක් "ගොඩනංවන ලද" වැඩ වටයක් නිර්මාණය කර ඇති බැවිනි. [...]

වෙනත් කරුණු:

• මකා වෙනුවට උමගක් ලෙස පත් භාවිතා / තැපැල් භාවිතා වැරදි අර්ථයක් ඇති වන තරග කල ගබඩා කිරීමට හේතු විය හැකි (උදා: POST ප්රතිචාරයන් cachable , Put ප්රතිචාර 6 නොවේ (), මකා දැමීම ප්රතිචාර 7 නොවේ ())
• අයිඩම්පොටෙන්ට් මෙහෙයුමක් (PUT / DELETE) සිදු කිරීම සඳහා අනන්‍යතා නොවන ක්‍රමයක් (POST) භාවිතා කිරීම ජාල අසමත්වීම් හේතුවෙන් ප්‍රකෘතිමත් වීම සංකීර්ණ කරයි (උදා: "මෙම ක්‍රියාව නැවත කිරීම ආරක්ෂිතද?").
• [...]

ඔහුගේ මුළු ලිපියම කියවීම වටී.

ටොම් වෝඩ්රොප් ද සිත්ගන්නා කරුණක් ඉදිරිපත් කරයි:

HTML වෙන් කළ නොහැකි ලෙස HTTP සමඟ බැඳී ඇත. HTML යනු HTTP හි මානව අතුරු මුහුණතයි. එබැවින් HTTP පිරිවිතරයේ ඇති සියලුම අදාළ ක්‍රම සඳහා HTML සහාය නොදක්වන්නේ මන්දැයි එය ස්වයංක්‍රීයව ප්‍රශ්න කරයි. යන්ත්‍රවලට PUT සහ DELETE සම්පත් කළ හැකි නමුත් මිනිසුන්ට එය කළ නොහැක්කේ ඇයි? [...]

අර්ථකථන සලකුණු කිරීම සහතික කිරීම සඳහා HTML බොහෝ දුරට ගියද, අර්ථකථන HTTP ඉල්ලීම් සහතික කිරීම සඳහා මේ දක්වා එවැනි උත්සාහයක් නොගැනීම පරස්පර විරෝධී ය.

දෝෂය අවසානයේදී ඉයන් හික්සන් විසින් Won't Fix ලෙස වසා දමන ලදී .

පෝරම ක්‍රමයක් ලෙස PUT තේරුමක් නැති දෙයක්, ඔබට පෝරමයක් ගෙවීමට අවශ්‍ය නැත. මකාදැමීම අර්ථවත් වන්නේ ගෙවීමක් නොමැති නම් පමණි, එබැවින් එය ආකෘති සමඟ එතරම් තේරුමක් නැත.

කෙසේ වෙතත්, එය කතාවේ අවසානය නොවේ! මෙම ගැටළුව W3C දෝෂ ට්රැකර් තුළ වසා දමා HTML ක්‍රියාකාරී කණ්ඩායම් නිකුතුව ට්රැකර් වෙත තීව්‍ර විය:

https://www.w3.org/html/wg/tracker/issues/195

මෙම අවස්ථාවෙහිදී, මෙම ක්‍රම සඳහා සහය නොලැබීමට ප්‍රධාන හේතුව වන්නේ ඒ සඳහා පුළුල් පිරිවිතරයක් ලිවීමට කිසිවෙකු කාලය ගත නොකිරීමයි.

BUT 10671 පෝට් ක්‍රම ලෙස PUT සහ DELETE සඳහා සහය එක් කිරීම සලකා බලන බැවින් මෙය 2010 දී මතු කරන ලදී .

මෙම "විශේෂාංගය" සඳහා යම් තරමක තල්ලු කිරීමක් සහ යම් තරමක හස්තයක් ඇති නමුත් අවසානයේදී මෙය ක්‍රියාකාරී කණ්ඩායම් දෝෂ සොයාගැනීමේදී ගැටළු දෙකක් ලෙස තීව්‍ර විය:

• ISSUE-195: පෝරම වලින් http ඉල්ලීම් උත්පාදනය වැඩි දියුණු කරන්න
• ISSUE-196: පරිශීලක නියෝජිත http ප්‍රතිචාර හැසිරවීමේ හැසිරීම නිර්වචනය කරන්න

ISSUE-196 නිකුතුවෙහි ප්‍රති ulted ලයක් ලෙස පිරිවිතරයන්ට කිසිදු වෙනසක් සිදු නොකිරීමට එකඟතාවයකට පැමිණ ඇති අතර, HTML පිරිවිතරයන් දැනට POST ඉල්ලීම් වලට ප්‍රතිචාර දක්වන්නේ කෙසේද යන්න සීමා නොකරයි. පොදුවේ භාවිතයේ පවතින POST යළි-යොමුවීම් රටා සැසඳීමට උත්සාහ කිරීමේදී සහ බ්‍රවුසරයක විදැහුම් කිරීමට ප්‍රයෝජනවත් දෙයකට වඩා කෙටි පණිවිඩ සමඟ 2xx ප්‍රතිචාර බොහෝ විට සපයන්නේ කෙසේද යන්න මෙම විශේෂිත ප්‍රශ්නය මතු වූ බව මම විශ්වාස කරමි.

ISSUE-195 නිකුතුව පුටු වෙත ඉදිරිපත් කරන ලදී. කැමරන් ජෝන්ස් විසින් 2012 ජනවාරි 18 වන දින වෙනස් කිරීමේ යෝජනාවක් ලිවීමට ස්වේච්ඡාවෙන් ඉදිරිපත් වූ අතර එය 2014 මැයි 29 වන දින පළමු වැඩ කෙටුම්පත බවට පත් කිරීමට ඉදිරිපත් කරන ලදී . කෙටුම්පත W3C නිර්දේශ ක්‍රියාවලිය හරහා ගමන් කරනු ඇත.

ඕනෑම වාසනාවකට, මෙය ඉතා ඉක්මනින් W3C නිර්දේශයක් බවට පත්ව බ්‍රව්සර් වෙළෙන්දන් විසින් ක්‍රියාවට නංවනු ඇති අතර, ඒකාබද්ධ, අර්ථකථන සහ බ්‍රව්සර් හිතකාමී ප්‍රතිස්ථාපන සේවා නිෂ්පාදනය කිරීම සඳහා අවහිර කරන්නන් ඉවත් කිරීමේ විශාල ඉදිරි පියවරක් වනු ඇත. මෙය සේවා රටාවන්හි සිත්ගන්නාසුලු පරිණාමයක් ඇති කරනු ඇතැයි මම සිතමි. ජෝන් මුවර්ගේ හොඳ කතාවක් තිබේ - හයිපර්මීඩියා ඒපීඅයි නැරඹීම වටී, මෙය මගේ උනන්දුව ඇති නමුත් පළමු කඩුල්ලට වැටුණි (මෙය).

GET සහ POST හි පැහැදිලි අන්තර්ගත-උදාසීන තාර්කිකත්වයක් ඇත. GET යනු URL එකක අන්තර්ගතය නැවත නැවත ආරක්‍ෂිත හා නැවත හැඹිලිය සඳහා ලබා ගැනීමයි. POST යනු නැවත නැවත කිරීමට, සමපේක්ෂන ලෙස ක්‍රියාත්මක කිරීමට හෝ හැඹිලියට ආරක්ෂිත නොවන ආකාරයකින් යමක් කිරීමයි.

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

එබැවින් මූලික වශයෙන් කිසිදු ප්‍රතිලාභයක් නොමැත.

මගේ අවබෝධය නම්, බ්‍රව්සර් PUT හෝ DELETE යැවූ පසු කුමක් කළ යුතු දැයි නොදන්නා බවයි. POST සාමාන්‍යයෙන් සුදුසු පිටුවකට හරවා යවනු ඇත, නමුත් PUT සහ DELETE සාමාන්‍යයෙන් එසේ නොවේ. මෙය ඔවුන් අජැක්ස් හෝ ස්වදේශීය වැඩසටහනක් හරහා ඇමතීමට සුදුසු නමුත් වෙබ් බ්‍රව්සර ආකෘතියකින් නොවේ.

මට දැන් එයට බාධා කළ නොහැක, නමුත් මට මතකයි ඔවුන් මේ ගැන සාකච්ඡා කරන විට html5 තැපැල් ලැයිස්තුවක් කියවීම.

ඉතිහාසය

RFC1866 (8.1 වගන්තිය) හි HTML ආකෘතිවල පළමු පෙනුම සඳහන් කිරීම වටී යැයි මම සිතමි . මෙන්න ක්‍රමවේදය ගුණාංගය පහත පරිදි අර්ථ දැක්වේ:

METHOD
        selects a method of accessing the action URI. The set of
        applicable methods is a function of the scheme of the
        action URI of the form. See 8.2.2, "Query Forms:
        METHOD=GET" and 8.2.3, "Forms with Side-Effects:
        METHOD=POST".

වැඩිදුර විස්තර 8.2.2 - GET සහ 8.2.3 - POST වගන්තියේ ඇත

මතක තබා ගන්න, HTML 2.0 (නොවැ. 1995) HTTP 1.0 (1996 මැයි) ට පෙර නියම කර ඇති බව . එබැවින් සෑම කෙනෙකුම HTTP භාවිතා කළේ GET සමඟ (HTTP 0.9 අනුව) හෝ POST දිගුව සමඟ පමණි. නමුත් PUT සහ DELETE සඳහා සහය දක්වන වෙබ් සේවාදායකයන් කිහිපයක් පමණි ( HTTP 1.0 උපග්‍රන්ථයේ සඳහන් පරිදි ).

සිතුවිලි

බර්නර්ස්-ලීගේ අර්ථකථන වෙබ් අඩවි සංවර්ධනය විකාශනය වූයේ කෙසේද යන්න ගැන ඔබ සිතන්නේ නම්, එය සත්‍ය ගැටලුවලින් සාමාන්‍ය සංකල්පයකට ගිය බව පැහැදිලිය. මුලින්ම ඔහුට ලේඛන බෙදා ගැනීමට අවශ්‍ය විය. එබැවින් ඔහුට ලකුණු කිරීම අවශ්‍ය විය. එවිට ඔහුට අන්තර්ගතය සඳහා දත්ත සමුදායන් විමසීමට අවශ්‍ය විය, එබැවින් ඔහුට ආකෘති අවශ්‍ය විය. ඉන්පසු ඔහුට අවශ්‍ය වූයේ නව දත්ත සමුදායට ඇතුළත් කිරීමයි. එබැවින් ඔහු GET සහ POST සමඟ ආකෘති භාවිතා කළේය. දුරස්ථ සිට දත්ත මත සෑම CRUD මෙහෙයුමක්ම ඔබට කළ හැකි බව ඔහු තේරුම් ගෙන ඇති නිසා HTTP දීර් extended කර ඇති නමුත් එය කිසි විටෙකත් ප්‍රමාද නොවූ හෙයින් HTML කිසි විටෙකත් (නව CRUD මෙහෙයුම් සඳහා සහය දැක්වූයේ සේවාදායකයන් කිහිපයක් පමණි).

හුදෙක් අනුමාන කිරීමක් කිරීම, නමුත් බොහෝ විට HTTP හොඳම වේලාවට ප්‍රවේශ පාලනය සමඟ එතරම් හොඳ නැති නිසාත්, සෑම කෙනෙකුටම අවශ්‍ය අන්තිම දෙය අනිෂ්ට URL සඳහා දුර්වල ආරක්‍ෂිත වෙබ් අඩවියක් සහ / හෝ යෙදුමක් සමඟ සම්මුතියක් ඇති කර ගැනීමට ඊටත් වඩා ක්‍රම වේ.

HTTP සැබවින්ම සේවාදායකයෙන් සේවාදායකයා වෙත බාගත කිරීම හැර ගොනු මාරු කිරීම් සඳහා හොඳ ප්‍රොටෝකෝලයක් නොවේ. FTP භාවිතා කරන්න - හෝ වඩා හොඳ තවමත්, SFTP.

ලබා ගැනීම සහ පළ කිරීම යනු ඉල්ලීමේ දත්ත සම්ප්‍රේෂණය කිරීමේ ආකෘති වේ.

ආකෘතිමය සේවාවක් සඳහා ඉදිරිපත් කිරීම ගැන ඔබ විමසනු ඇතැයි සිතමු. නමුත් http ඉල්ලීමේ අරමුණ උපකල්පනය කිරීම සඳහා http ඉල්ලීම් ප්‍රමිතිය වෙනස් කිරීම අර්ථවත් නොවේ. ඉල්ලීම පුරවන අරමුණ පිළිබඳ තොරතුරු ආදාන ක්ෂේත්‍ර තුළ වඩාත් හොඳින් හසුරුවනු ලැබේ.

ලිපිනයක් තිබීම සහ ලබා ගැනීම සහ පළ කිරීම සේවාදායකයාට ඉල්ලීම අර්ථ නිරූපණය කිරීමට ඉඩ දෙන අතර එහි ආදාන අගයන් නිවැරදිව වේ. එතැන් සිට ආදාන අගයන් මඟින් සේවාදායකයාට විවෘත ඉල්ලීම් කිරීමට සහ ඔබට අවශ්‍ය ඕනෑම දෙයක් කිරීමට ඉඩ ලබා දේ. උදාහරණයක් ලෙස, ඔබට "දමා" සහ "මකන්න" යන අගයන් ඇති ක්ෂේත්‍රයක් තිබිය හැකිය