සම්පත් දැනටමත් පවතින විට POST සඳහා HTTP ප්‍රතිචාර කේතය

883

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

PUT භාවිතයෙන් වස්තු නිර්මාණය කිරීමට හෝ වෙනස් කිරීමට සේවාදායකයින්ට හැකි වන පරිදි මම API නිර්වචනය කර ඇත:

PUT /objects/{id} HTTP/1.1
...

{json representation of the object}

{Id the යනු වස්තු හැඳුනුම්පත වන බැවින් එය ඉල්ලීම්- URI හි කොටසකි.

දැන්, POST භාවිතයෙන් වස්තුව නිර්මාණය කිරීමට ගනුදෙනුකරුවන්ට ඉඩ දීම ගැන ද මම සලකා බලමි:

POST /objects/ HTTP/1.1
...

{json representation of the object, including ID}

POST යන්න "උපග්‍රන්ථය" මෙහෙයුමක් ලෙස අදහස් කර ඇති හෙයින්, වස්තුව දැනටමත් තිබේ නම් කුමක් කළ යුතුදැයි මට විශ්වාස නැත. මම ඉල්ලීම වෙනස් කිරීමේ ඉල්ලීමක් ලෙස සැලකිය යුතුද? නැතහොත් යම් දෝෂ කේතයක් (කුමන) ආපසු ලබා දිය යුතුද?

rest  http  http-status-codes 
— vmj
source
5
2016 ජුනි මස වන විට FB විද්‍යුත් තැපෑල පවතින විට 200 ක් ලියාපදිංචි කිරීම සඳහා
— Green
4
දැනටමත් භාවිතයේ පවතින නමක් සහිත සම්පතක් (කණ්ඩායම් / රෙපෝ) නිර්මාණය කිරීමට උත්සාහ කරන විට ගිතුබ් ඒපීඅයි 422 ලබා දෙයි
— කෙන්
1
එය රඳා පවතින්නේ ඔබ වස්තුවේ පැවැත්ම දෝෂයක් ලෙස සලකන්නේද නැද්ද යන්නයි. ඔබ උපග්‍රන්ථය සකසන්නේ නම්, 200 හෝ 204 වඩාත් සුදුසු ප්‍රතිචාර කේත වේ.
— සන්කැට් 2000

Answers:

1122

මගේ හැඟීම 409 Conflictවඩාත් උචිත ය, කෙසේ වෙතත්, කලාතුරකින් දක්නට ලැබෙන්නේ කලාතුරකිනි:

සම්පතෙහි වත්මන් තත්වය සමඟ ගැටුමක් හේතුවෙන් ඉල්ලීම සම්පූර්ණ කළ නොහැකි විය. මෙම කේතය අවසර දී ඇත්තේ ගැටුම නිරාකරණය කර ඉල්ලීම නැවත ඉදිරිපත් කිරීමට පරිශීලකයාට හැකි වනු ඇතැයි අපේක්ෂා කරන අවස්ථාවන්හිදී පමණි. ප්‍රතිචාර ශරීරය ගැටුමේ ප්‍රභවය හඳුනා ගැනීමට පරිශීලකයාට ප්‍රමාණවත් තොරතුරු ඇතුළත් කළ යුතුය. ඉතා මැනවින්, ප්‍රතිචාර ආයතනයට ගැටළුව විසඳීමට පරිශීලකයාට හෝ පරිශීලක නියෝජිතයාට ප්‍රමාණවත් තොරතුරු ඇතුළත් වේ; කෙසේ වෙතත්, එය කළ නොහැකි විය යුතු අතර අවශ්‍ය නොවේ.

PUT ඉල්ලීමකට ප්‍රතිචාර වශයෙන් ගැටුම් ඇතිවීමට බොහෝ දුරට ඉඩ ඇත. නිදසුනක් ලෙස, අනුවාදකරණය භාවිතා කරන්නේ නම් සහ PUT යන ආයතනයට පෙර (තෙවන පාර්ශවීය) ඉල්ලීමක් මගින් කරන ලද සම්පතකට වෙනස්කම් ඇතුළත් කර ඇත්නම්, සේවාදායකයාට 409 ප්‍රතිචාරය භාවිතා කර ඉල්ලීම සම්පූර්ණ කළ නොහැකි බව දැක්වීමට භාවිතා කළ හැකිය. . මෙම අවස්ථාවෙහිදී, ප්‍රතිචාරයේ අන්තර්ගතය වර්ගය මඟින් අර්ථ දක්වා ඇති ආකෘතියක අනුවාද දෙක අතර ඇති වෙනස්කම් ලැයිස්තුවක් අඩංගු වේ.

— රිකන්
source
13
නරක ඉල්ලීම් 400 ක් සඳහා නොයන්නේ ඇයි? මට නම් මෙය වලංගු කිරීමේ දෝෂයක් සේ පෙනේ (ඔබ නීති විරෝධී හැඳුනුම්පත සමඟ වැරදි ගෙවීමක් සපයයි).
— මැනුවෙල් අල්ඩානා
326
400 => "අක්‍රීය සින්ටැක්ස් නිසා ඉල්ලීම සේවාදායකයාට තේරුම් ගත නොහැකි විය" . සේවාදායකයා හොඳින් වටහාගෙන ඇති නමුත් ගැටුමක් හේතුවෙන් එයට අනුකූල විය නොහැක. ඉල්ලීම සහ වාක්‍ය ඛණ්ඩයේ කිසිදු වරදක් නොමැත, දත්ත ගැටළුවක් පමණි. 400 ක් ක්ෂණිකව මා විශ්වාස කරන්නේ දත්ත වෙනුවට මම භාවිතා කරන සමස්ත යාන්ත්‍රණයම දෝෂ සහිත බවයි.
— රිකන්
46
Ri රිකන් එය තවදුරටත් නිවැරදි නොවේ. HTTP 400 වෙනස් විය RFC 7231 එයින් අදහස් කරන්නේ "සේවාදායකය නොහැකි හෝ නැත හේතුවෙන් සේවාලාභී දෝෂයක් (උදා, විකෘති ඉල්ලීම කාරක රීති, වලංගු නොවන ඉල්ලීමක් පණිවිඩය රාමු, හෝ කූට ඉල්ලීම මගින් මාර්ගගත) යුතු බව පෙනේ දෙයක් කිරීමට ඉල්ලීම ක්රියා." මෙම නඩුවේ 400 යනු නිවැරදි භාවිතය යැයි මම නොකියමි, නමුත් 400 හි නව අර්ථ දැක්වීම සමඟ එය නිවැරදි විය හැකිය.
— javajavajavajavajava
21
avajavajavajavajavajava: තවමත්, අනුපිටපත් දත්ත මගේ මනසෙහි 'සේවාදායක දෝෂයක්' නොවේ, නමුත් එය ඇත්ත වශයෙන්ම නරඹන්නාගේ ඇසෙහි ඇත.
— රිකන්
28
පවතින / පරස්පර සම්පත වෙත යොමු කරමින් මම ආපසු HTTP 409යමි Location.
— ගිලි
110

RFC 7231 ට අනුව , 303 බලන්න වෙනත් MAY භාවිතා කළ හැකිය POST සැකසීමේ ප්‍රති result ලය පවත්නා සම්පතක් නිරූපණය කිරීමට සමාන වේ .

— නුලියස්
source
4
මගේ මතය අනුව, මෙය පිළිගත් පිළිතුර විය හැකිය. "MAY" යන්නෙන් සම්පූර්ණයෙන්ම විකල්ප අයිතමයක් දැක්වුවද , නිල RFC 7231 ප්‍රලේඛනය මඟින් යෝජනා කරන එකම ප්‍රතිචාර කේතය එයයි.
— නන්දෝ
17
මෙය වඩාත්ම RESTful පිළිතුරයි.
— සෙත්
6
සන්දර්භය වැදගත් යැයි මම සිතමි. උදාහරණයක් ලෙස: 303 ආපසු ලබා දීමෙන් ඇඟවෙන්නේ සොයාගත් සම්පත වෙත යළි හරවා යැවීමක් අවශ්‍ය බවයි. සේවාදායකයෙකුට සේවාදායක ඇමතුමකට එය අර්ථවත් විය හැකි නමුත්, ඔබ පරිශීලක ලියාපදිංචි කිරීමේ ක්‍රියාවලියක් හරහා ගමන් කරන්නේ නම්, එය කිසිසේත්ම තේරුමක් නැත.
— සීනෙස්ටෙටික්
14
කණගාටුයි, මම මෙය පහත් කොට සලකමි. HTTP 300s නැවත හරවා යැවීම ගැන වන අතර විවිධ ගුණාංග ඇති වෙනත් වස්තුවකට හරවා යැවීම ඉතා නොමඟ යවන සුළුය.
— මයිකල් ෂෙපර්
6
ඔබට කණගාටු විය යුතු නැත. කෙසේ වෙතත්, නිරූපණය පවත්නා සම්පතකට සමාන නම්, එයට වෙනස් ගුණාංග තිබිය හැක්කේ කෙසේද? එය තිබුනත්, යළි-යොමුවීමක් නොමඟ යවන්නේ කෙසේද? OP පවසයි: වස්තුව දැනටමත් තිබේ නම් කුමක් කළ යුතුදැයි මට විශ්වාස නැත. එය ඇත්ත වශයෙන්ම 'එකම' වස්තුවයි. යළි-යොමුවීමක් නොමඟ යවන්නේ ඇයි? ඔබ කතා කරන්නේ OP හි මනසෙහි පැහැදිලිවම නැති වෙනත් වස්තුවක් ගැන ය.
— නුලියස්
91

පුද්ගලිකව මම WebDAV දිගුව සමඟ යමි 422 Unprocessable Entity.

RFC 4918 ට අනුව

මෙම 422 Unprocessable Entityතත්ත්වය කේතය සේවාදායකය ඉල්ලීම ආයතනයක් (ඒ වන අන්තර්ගතය වර්ගය අවබෝධ අදහස් 415 Unsupported Media Typeතත්ත්වය කේතය නුසුදුසු), සහ ඉල්ලීම ආයතනෙයහි කාරක රීති නිවැරදි (එනයින් 400 Bad Requestතත්ත්වය කේතය නුසුදුසු) නමුත් අඩංගු උපදෙස් කටයුතු කිරීමට නොහැකි විය.

— ගරෙත්
source
19
මෙය සිත්ගන්නාසුලු සිතුවිල්ලක් වන අතර අවසානයේ WebDAV RFC කියවීමට මා පෙලඹුණි. කෙසේ වෙතත්, මම සිතන්නේ 422 හි අර්ථය වන්නේ ඉල්ලීම සහ ඇතුළත් කළ ආයතනය කෘතිමව නිවැරදි නමුත් අර්ථාන්විතව තේරුමක් නැති බවය.
— vmj
5
විකෘති JSON යනු 422
— කෘතිමව
7
මම මේ සමඟ යන්නේ නැහැ. පිළිතුරෙහි සඳහන් කර ඇති එකම URL එකෙන්: "නිදසුනක් ලෙස, XML ඉල්ලීම් ආයතනයක හොඳින් සාදන ලද (එනම්, කෘතිමව නිවැරදි), නමුත් අර්ථාන්විතව වැරදි, XML උපදෙස් තිබේ නම් මෙම දෝෂ තත්වය ඇතිවිය හැකිය." ඔබ වලංගු සින්ටැක්ස් සහ අර්ථකථන සමඟ සම්පුර්ණයෙන්ම වලංගු ඉල්ලීම් ආයතනයක් යවන විට මෙන් නොව, සැකසිය නොහැකි ආයතනයක සැබෑ අරුත මෙයයි, නමුත් එකම ගැටළුව එය පවතින ආයතනයක් සමඟ ගැටීමයි. ඇත්ත වශයෙන්ම, ඉල්ලීම් ආයතනයේ අර්ථ නිරූපණය වලංගු නොවේ නම්, ඒ හා සමාන, පවතින ආයතනයක් කිසිසේත් නොතිබිය යුතුය.
— ටමර් ෂ්ලෑෂ්
1
ටමර් අදහස් දැක්වීමට එකතු කිරීම, දෙවන ඉල්ලීම පළමුව පැමිණියේ නම්, එය සාර්ථක වනු ඇත, එය අර්ථාන්විතව නිවැරදි නම් එය කළ නොහැකි වනු ඇත. එබැවින් නිවැරදි අර්ථ නිරූපණයන් මෙහි අදාළ නොවේ.
— හරීෂ්
4
Ame ටමර් ඇයි එසේ? "කරුණාකර වස්තුව xy සාදන්න" විධානය කෘතිමව නිවැරදි ය. එය අර්ථාන්විතව නිවැරදි වන්නේ xy වස්තුව නිර්මාණය කළ හැකි නම් පමණි. Xy වස්තුව දැනටමත් පවතී නම්, එය තවදුරටත් නිර්මාණය කළ නොහැක, එබැවින් මෙය අර්ථකථන දෝෂයකි.
— හේගන් වොන් එයිට්සන්
53

මේ සියල්ල සන්දර්භය පිළිබඳ වන අතර ඉල්ලීම්වල අනුපිටපත් හැසිරවීමට වගකිව යුත්තේ කවුරුන්ද (සේවාදායකයා හෝ සේවාදායකයා හෝ දෙකම)

සේවාදායකය අනුපිටපත යොමු කරන්නේ නම් , 4xx දෙස බලන්න:

  • 400 නරක ඉල්ලීම - සේවාදායකයාගේ දෝෂයක් නිසා සේවාදායකයා ඉල්ලීමක් ක්‍රියාවට නංවන්නේ නැත
  • ගැටුම - සේවාදායකයා ඉල්ලීමක් ක්‍රියාවට නංවන්නේ නැත්නම්, ඒ සඳහා හේතුව සේවාදායකයාගේ වරද නොවේ
  • ...

සඳහා ගම්ය අනුපිටපත් හසුරුවාලීමට, 2XX සලකා බලන:

  • 200 හරි
  • 201 නිර්මාණය
  • ...

සේවාදායකයා යමක් ආපසු ලබා දෙනු ඇතැයි අපේක්ෂා කරන්නේ නම් , 3XX දෙස බලන්න:

  • 302 හමු විය
  • වෙනත් බලන්න
  • ...

සේවාදායකයාට පවතින සම්පත යොමු කිරීමට හැකි වූ විට, එය යළි හරවා යැවීමක් අදහස් කරයි.

ඉහත සඳහන් දෑ ප්‍රමාණවත් නොවේ නම්, ප්‍රතිචාරයේ ශරීරයේ යම් දෝෂ පණිවිඩයක් සකස් කිරීම සැමවිටම හොඳ පුරුද්දකි.

— සාවොමිර් ලෙනාට්
source
2
ඉල්ලීම සම්පතක් අනුපිටපත් කිරීමක් නොවේ, එය එකකට දත්ත එකතු කරයි. මගේ මතය අනුව, සියල්ලටම හොඳම පිළිතුර ඔබේ ය.
— සන්කැට් 2000
28

ක්‍රීඩාවට ප්‍රමාද විය හැකි නමුත් REST API එකක් සෑදීමට උත්සාහ කරන අතරතුර මම මෙම අර්ථකථන ගැටලුවට බාධා කළෙමි.

රිකන් ගේ පිළිතුරෙන් ටිකක් පුළුල් කිරීම සඳහා, ඔබට 409 Conflictහෝ 403 Forbiddenතත්වය මත පදනම්ව භාවිතා කළ හැකි යැයි මම සිතමි - කෙටියෙන් කිවහොත්, ගැටුම නිරාකරණය කර ඉල්ලීම සම්පුර්ණ කිරීමට පරිශීලකයාට කිසිවක් කළ නොහැකි විට 403 දෝෂයක් භාවිතා කරන්න (උදා: ඔවුන්ට යැවිය නොහැක DELETEසම්පත පැහැදිලිව ඉවත් කිරීමට ඉල්ලන්න), නැතහොත් යමක් කළ හැකි නම් 409 භාවිතා කරන්න.

10.4.4 403 තහනම්

සේවාදායකයා ඉල්ලීම තේරුම් ගත් නමුත් එය ඉටු කිරීම ප්‍රතික්ෂේප කරයි. බලය පැවරීම උදව් නොකරන අතර ඉල්ලීම නැවත නොකෙරේ. ඉල්ලීමේ ක්‍රමය HEAD නොවූයේ නම් සහ ඉල්ලීම ඉටු නොවීමට හේතුව සේවාදායකයා විසින් ප්‍රසිද්ධියට පත් කිරීමට කැමති නම්, එම ආයතනය ප්‍රතික්ෂේප වීමට හේතුව එය විස්තර කළ යුතුය. සේවාදායකයාට මෙම තොරතුරු ලබා දීමට සේවාදායකයා අකමැති නම්, ඒ වෙනුවට 404 (සොයාගත නොහැකි) තත්ව කේතය භාවිතා කළ හැකිය.

වර්තමානයේදී, යමෙකු "403" යැයි පවසන අතර අවසර හෝ සත්‍යාපන ගැටළුවක් මතකයට එයි, නමුත් පිරිවිතර පවසන්නේ එය මූලිකවම සේවාදායකයා සේවාදායකයාට එය සිදු නොකරන බවත් නැවත එය විමසන්න එපා බවත් සේවාදායකයා එසේ නොකළ යුත්තේ ඇයිද යන්නයි. 'ටී.

සඳහා පරිදි PUTඑදිරිව POST... POSTපරිශීලක කිසිදු වත්කමක් ඇති හෝ සම්පත් සඳහා හඳුනාගැනීමේ නිර්මාණය කළ යුතු විට සම්පතක් නව උදාහරණයක් නිර්මාණය කිරීම සඳහා භාවිතා කළ යුතුය. PUTසම්පත් අනන්‍යතාවය දැනගත් විට භාවිතා වේ.

9.6 PUT

...

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

එය 301 (ස්ථිරව ගෙන යන) ප්‍රතිචාරයක් යැවිය යුතුය; පරිශීලක නියෝජිතයා පසුව ඉල්ලීම හරවා යැවිය යුතුද නැද්ද යන්න පිළිබඳව තමන්ගේම තීරණයක් ගනී.

— p0lar_bear
source
8
මම හිතන්නේ 403 තහනම් කර ඇති පරිදි, පරිශීලකයා සත්‍යාපනය කර ඇතත් , ඉල්ලූ ක්‍රියාව ක්‍රියාත්මක කිරීමට ඔහුට අවසර නැත . වලංගු කිරීමේ දෝෂ සඳහා මම එය භාවිතා නොකරමි. උදාහරණය : පුරනය වී නැත, මම යමක් මකා දැමීමට උත්සාහ කරමි. සේවාදායකයා මට 401 අනවසරයෙන් යවයි (එය නරක ලෙස නම් කර ඇත, සත්‍යාපනය නොකළ 401 විය යුතුය ). මම ලොග් වී නැවත උත්සාහ කරමි. මේ වතාවේ සේවාදායකයා මගේ අවසරයන් පරික්ෂා කර බැලූ විට, මට අවසර නැති බව දැක 403 තහනම් කර ඇත. මෙම ප්‍රශ්නය ද බලන්න .
— ස්ටිජන් ඩි විට්
හ්ම් ... ඇත්ත. මෙහි සිතුවිල්ල පරිශීලකයාට ඔවුන්ගේ අවසරය OP හි භාවිතයේ දී වෙනස් කළ නොහැකි බව පැවසීමට දකුණට පනී - එය දැනටමත් පවතී, ගැටුම නිරාකරණය කිරීම සඳහා ඔබට කිසිවක් කිරීමට අවසර නැත, සම්පත නැවත නිර්මාණය කිරීමට උත්සාහ නොකරන්න.
— p0lar_bear
3
පිරිවිතරයට අනුව, 409 දෝෂය POSTඉල්ලීමකින් ආපසු ලබා දිය නොහැකි බව අඟවයි (නිවැරදිව භාවිතා කරන විට), එය සඳහන් කරන්නේ ඉලක්කගත සම්පත සමඟ ගැටෙන විට එය ආපසු ලබා දිය යුතු බවයි . ඉලක්කගත සම්පත තවම පළ කර නොමැති බැවින් එයට ගැටුම් ඇති විය නොහැකි අතර ඒ අනුව පිළිතුරු 409 Conflictදීම අර්ථවත් නොවේ.
— ග්‍රාන්ට් ග්‍රික්සන්
1
409 දෝෂයක් ආපසු ලබා දිය නොහැකි බව POSTමම අනුමාන නොකරමි, ඇත්ත වශයෙන්ම, මම ප්‍රතිවිරුද්ධ දෙය අනුමාන කරමි, මන්ද " PUT ඉල්ලීමකට ප්‍රතිචාර වශයෙන් ගැටුම් බොහෝ විට සිදුවිය හැකි බැවිනි." වෙනත් ඉල්ලීම් ක්‍රමවලටද මෙම කේතය භාවිතා කළ හැකි බව පෙනේ. මීට අමතරව, " ගැටුමේ මූලාශ්‍රය හඳුනා ගැනීම සඳහා ප්‍රතිචාර ආයතනයට ප්‍රමාණවත් තොරතුරු ඇතුළත් විය යුතුය . ඉතා මැනවින්, ප්‍රතිචාර දැක්වීමේ ආයතනයට ගැටළුව විසඳීම සඳහා පරිශීලකයාට හෝ පරිශීලක නියෝජිතයාට ප්‍රමාණවත් තොරතුරු ඇතුළත් වේ; කෙසේ වෙතත් එය කළ නොහැකි විය හැකි අතර අවශ්‍ය නොවේ . ( webdav.org/specs/rfc2616.html#status.409 )
— JWAspin
12

"302 හමු විය" මට තර්කානුකූලයි. සහ නේවාසික විදේශ ව්යවහාර මුදල් 2616 (මෙම නියත වශයෙන්ම තැපැල් ඇතුලත් වේ) එය ලබා ගැනීමට හා හිස වඩා අනෙකුත් ඉල්ලීම් සඳහා පිළිතුරු ලබා දිය හැකි බව පවසයි

නමුත් එය තවමත් RFC විසින් මෙම "සොයාගත්" සම්පත ලබා ගැනීම සඳහා අමුත්තන්ට මෙම URL වෙත යයි. එය සත්‍ය "සොයාගත්" URL වෙත කෙලින්ම යාමට නම්, "303 වෙනත් බලන්න" භාවිතා කළ යුතුය, එය අර්ථවත් කරයි, නමුත් තවත් ඇමතුමක් එහි පහත URL ලබා ගැනීමට බල කරයි. හොඳ පැත්තෙන්, මෙම GET හැඹිලිගත කළ හැකිය.

මම හිතන්නේ "303 වෙනත් බලන්න" . ශරීරයේ ඇති "දෙය" සමඟ මට ප්‍රතිචාර දැක්විය හැකිදැයි මම නොදනිමි, නමුත් එක් වට රවුමක් සේවාදායකයට සුරැකීමට මම එසේ කිරීමට කැමැත්තෙමි.

UPDATE: මේ RFC නැවත කියවීමෙන් පසු, මම තවමත් හිතන්නේ inexistent "4XX + 303 හමු" කේතය නිවැරදි විය යුතුය. කෙසේ වෙතත්, "409 ගැටුම" යනු දැනට පවතින හොඳම පිළිතුරු කේතයයි (@Wrikken විසින් පෙන්වා දී ඇති පරිදි), සමහර විට පවතින සම්පත වෙත යොමු වන ස්ථාන ශීර්ෂයක් ද ඇතුළුව.

— alanjds
source
95
3xx තත්වයන් යළි හරවා යැවීම සඳහා අදහස් කෙරේ
— අවිරාම් නෙටනෙල්
1
"ඉල්ලූ සම්පත තාවකාලිකව වෙනත් යූආර්අයි යටතේ වාසය කරයි." w3.org/Protocols/rfc2616/rfc2616-sec10.html
— statueofmike
1
IMHO, "307 තාවකාලික යළි-යොමුවීම" යනු සැබෑ තාවකාලික යළි-යොමුවීමයි. "302" අපැහැදිලි ය, නමුත් "FOUND !!" මෙහි සැබවින්ම අපේක්ෂිත පණිවිඩය වේ. හොඳම නිසැක සම්මුතිය වන්නේ HTTP අර්ථ නිරූපණයන්හි "303 වෙනත් බලන්න" යන්නයි. මම "වෙනත් 303 බලන්න" සමඟ යන්නෙමි.
— alanjds
Av ඩේවිඩ්වර්ටේනියන් හම් ... මට මෙහි දෝෂයක් නොපෙනේ. සේවාදායකයා නිවැරදි ඉල්ලීමක් යවයි, නමුත් "සමාවෙන්න, නමුත් ඔබ මෙහි නිර්මාණය කිරීමට උත්සාහ කරන දේ දැනටමත් පවතී" යැයි පවසන්නේ කෙසේද? 3xx සඳහා රැකියාවක් පෙනේ. සේවාදායක දෝෂයක් නොමැති බැවින් එය මට 4xx නොවේ.
— alanjds
1
Av ඩේවිඩ්වර්ටේනියන් සාකච්ඡාවට ස්තූතියි. පිළිතුර 409 දෙසට යාවත්කාලීන කරන ලදි . කළ නොහැකි දේ නොදැන සේවාදායකයා කළ නොහැකි දේ ඉල්ලීම වැරදිය.
— alanjds
11

මම හිතන්නේ නැහැ ඔබ මෙය කළ යුතුයි.

POST යනු ඔබ දන්නා පරිදි, එකතුව වෙනස් කිරීම සඳහා වන අතර එය නව අයිතමයක් නිර්මාණය කිරීමට භාවිතා කරයි. එබැවින්, ඔබ හැඳුනුම්පත යවන්නේ නම් (එය හොඳ අදහසක් නොවන බව මම සිතමි), ඔබ එකතුව වෙනස් කළ යුතුය, එනම් අයිතමය වෙනස් කළ යුතුය, නමුත් එය අවුල් සහගතය.

හැඳුනුම්පතක් නොමැතිව අයිතමයක් එක් කිරීමට එය භාවිතා කරන්න. එය හොඳම පුහුණුවයි.

ඔබට UNIQUE අවහිරයක් අල්ලා ගැනීමට අවශ්‍ය නම් (හැඳුනුම්පත නොවේ) ඔබට PUT ඉල්ලීම් වලදී කළ හැකි පරිදි 409 ට ප්‍රතිචාර දැක්විය හැකිය. නමුත් හැඳුනුම්පත නොවේ.

— ඇල්ෆොන්සෝ ටියැන්ඩා
source
සම්බන්ධ වීමේ වගු සම්බන්ධතාවයක් ඇති වස්තුවක් ගැන කුමක් කිව හැකිද? දත්ත සමුදා වගු ලෙස අපට ගිණුම, නිෂ්පාදන සහ ගිණුම්_ප්‍රශ්න ඇති බව පවසන්න. මට ගිණුමකට නිෂ්පාදනයක් එක් කිරීමට අවශ්‍යයි, එබැවින් මට product_id සමඟ / ගිණුම / {id} / නිෂ්පාදනයට පළ කිරීමට අවශ්‍යය. එක් ගිණුම්-නිෂ්පාදන සම්බන්ධතාවයකට පමණක් අවසර දී ඇත්නම්, මා ආපසු යා යුත්තේ කුමක් ද?
— partkyle
2
දත්ත සමුදා වගු අමතක කරන්න. නිෂ්පාදනයක් සම්බන්ධ විය හැක්කේ ගිණුමකට පමණක් යැයි කියමු ... එවිට එය බොහෝ සම්බන්ධතාවයන්ගෙන් එකකි. එබැවින්, {'ගිණුම' සමඟ POST / product / {id}: account_id}. ඔබට උපරිම කාර්දිනල් භාවය '1' ලෙස සකසා තිබේ නම් (එකකට එක සම්බන්ධතාවයක්) .... ඒවා විවේක වස්තු වෙන් කරන්නේ ඇයි? කාර්දිනල් දෝෂයක් යනු දෝෂ 400 ක් පමණි. එය සරලව තබා ගන්න. මම හිතනවා ඔයාගේ ප්‍රශ්නය මට තේරුණා කියලා.
— ඇල්ෆොන්සෝ ටියැන්ඩා
මම මේ ප්‍රශ්නය ද ඉදිරිපත් කළ අතර මට නම් හැඳුනුම්පත දත්ත සමුදායේ තාක්ෂණික හැඳුනුම්පත නොව සමාගම් කේතය වැනි ය. මෙම යෙදුමේදී කළමනාකරණ පරිශීලකයෙකුට සමාගම් නිර්මාණය කළ හැකි අතර ඔවුන්ට කේතයක් ලබා දිය යුතුය. ඩීබී වගුවේ තාක්ෂණික හැඳුනුම්පතක් තිබියදීත්, පරිශීලකයා සඳහා වන සමාගම් හැඳුනුම්පත මෙයයි. එකම සමාගම් කේතය දැනටමත් තිබේ නම් මගේ නඩුවේදී මම 409 ක් ආපසු දෙන්නෙමි.
— ඇලෙක්ස්කෝඩ්
artPartkyle පොදු හැඳුනුම්පත් ලෙස PK භාවිතා කිරීම නවත්වන්න !!
— සිනෙස්ටෙටික්
සමහර ආයතනවලට හැඳුනුම්පත පමණක් නොව ඒවාට අද්විතීය සීමාවන් ඇත. පරිශීලකයෙකු පරිශීලක නාමය ලබා නොදෙන්නේ නම් ගිණුමක් මෙන් ඔබට ගිණුමක් සෑදිය නොහැක. පරිශීලක නාමයක් නොමැති ගිණුමක් එක් කිරීම පැහැදිලිවම කළ නොහැක්කකි
— රොකට්ස්පේසර්
9

මම යනවා 422 Unprocessable Entityඉල්ලීමක් වලංගු නොවන විට භාවිතා කරන අතර මෙම ප්රශ්නය කාරක රීති හෝ අනන්යතාවය තහවුරු නොවන අතර,.

වෙනත් පිළිතුරු වලට එරෙහි තර්කයක් ලෙස, කිසියම් 4xxදෝෂ රහිත කේතයක් භාවිතා කිරීම එයින් ගම්‍ය වන්නේ එය සේවාදායක දෝෂයක් නොවන අතර එය පැහැදිලිවම ය. 4xxසේවාදායක දෝෂයක් නිරූපණය කිරීම සඳහා දෝෂ රහිත කේතයක් භාවිතා කිරීම කිසිසේත්ම තේරුමක් නැත.

මෙහි 409 Conflictවඩාත්ම පොදු පිළිතුර එය බව පෙනේ , නමුත්, පිරිවිතරයට අනුව, එයින් ඇඟවෙන්නේ සම්පත දැනටමත් පවතින බවත් ඔබ එයට යොදන නව දත්ත එහි වර්තමාන තත්වයට නොගැලපෙන බවත් ය. ඔබ යවන්නේ නම් අPOSTඋදාහරණයක් ලෙස, දැනටමත් ගෙන ඇති පරිශීලක නාමයක් සමඟ ඉල්ලීම, එය සැබවින්ම ඉලක්කගත සම්පත සමඟ ගැටෙන්නේ නැත, මන්ද ඉලක්ක සම්පත් (ඔබ නිර්මාණය කිරීමට උත්සාහ කරන සම්පත) තවම පළ කර නොමැත. ගබඩා කර ඇති සම්පතේ අනුවාදය සහ ඉල්ලූ සම්පතේ අනුවාදය අතර ගැටුමක් ඇති විට එය අනුවාද පාලනය සඳහා විශේෂයෙන් දෝෂයකි. එම අරමුණු සඳහා එය ඉතා ප්‍රයෝජනවත් වේ, නිදසුනක් ලෙස සේවාදායකයා සම්පතේ පැරණි අනුවාදයක් හැඹිලි කර එම වැරදි අනුවාදය මත පදනම්ව ඉල්ලීමක් යවන අතර එය තවදුරටත් කොන්දේසි සහිතව වලංගු නොවේ. "මෙම අවස්ථාවේ දී, ප්‍රතිචාර නිරූපණයේ ප්‍රතිශෝධන ඉතිහාසය මත පදනම්ව වෙනස්කම් ඒකාබද්ධ කිරීම සඳහා ප්‍රයෝජනවත් තොරතුරු අඩංගු විය හැකිය." අනුවාද පාලනයට කිසිදු සම්බන්ධයක් නැති, එම පරිශීලක නාමය සමඟ වෙනත් පරිශීලකයෙකු නිර්මාණය කිරීමේ ඉල්ලීම සැකසිය නොහැකි ය.

වාර්තාව සඳහා, 422 යනු ඔබ දැනටමත් භාවිතයේ ඇති නමකින් ගබඩාවක් සෑදීමට උත්සාහ කරන විට GitHub භාවිතා කරන තත්ව කේතයයි.

— ග්‍රාන්ට් ග්‍රික්සන්
source
422 යනු වෙබ්ඩව් පිරිවිතර බැවින් REST API සඳහා මෙය භාවිතා කිරීමට මම උපදෙස්
— නොදෙමි
7

මම හිතන්නේ REST සඳහා, ඔබ එම පද්ධතියේ හැසිරීම පිළිබඳව තීරණයක් ගත යුතු අතර, එම අවස්ථාවේ දී, “නිවැරදි” පිළිතුර මෙහි දී ඇති පිළිතුරු යුවළයන්ගෙන් එකක් වනු ඇතැයි මම සිතමි. ඉදිරියට යාමට පෙර සේවාදායකයා විසින් නිවැරදි කළ යුතු වැරැද්දක් සිදු වූවාක් මෙන් හැසිරීම නැවැත්වීමට ඔබට අවශ්‍ය නම්, 409 භාවිතා කරන්න. ගැටුම සැබවින්ම එතරම් වැදගත් නොවන අතර ඉල්ලීම දිගටම කරගෙන යාමට අවශ්‍ය නම්, නැවත හරවා යැවීමෙන් ප්‍රතිචාර දක්වන්න සොයාගත් ආයතනයට සේවාදායකයා. මම හිතන්නේ නිසි REST APIs කෙසේ හෝ POST එකකින් පසුව එම සම්පත සඳහා GET අන්ත ලක්ෂ්‍යයට හරවා යැවීම (හෝ අවම වශයෙන් ස්ථාන ශීර්ෂය සැපයීම) විය යුතුය, එබැවින් මෙම හැසිරීම ස්ථාවර අත්දැකීමක් ලබා දෙනු ඇත.

සංස්කරණය කරන්න: ඔබ හැඳුනුම්පත ලබා දෙන බැවින් ඔබ PUT එකක් සලකා බැලිය යුතු බව ද සඳහන් කිරීම වටී. එවිට හැසිරීම සරල ය: "මට දැන් එහි ඇති දේ ගණන් ගන්නේ නැත, මේ දේ එහි තබන්න." තේරුම, කිසිවක් නොමැති නම්, එය නිර්මාණය වනු ඇත; යමක් තිබේ නම් එය ප්‍රතිස්ථාපනය වේ. සේවාදායකයා එම හැඳුනුම්පත කළමනාකරණය කරන විට POST වඩාත් සුදුසු යැයි මම සිතමි. මෙම සංකල්ප දෙක වෙන් කිරීමෙන් මූලික වශයෙන් එය සමඟ ගනුදෙනු කරන්නේ කෙසේදැයි ඔබට කියනු ඇත (එනම්, PUT පරමාදර්ශී බැවින් ගෙවීම් වලංගු වන තාක් කල් එය සැමවිටම ක්‍රියාත්මක විය යුතුය, POST සැමවිටම නිර්මාණය වේ, එබැවින් හැඳුනුම්පත් ision ට්ටනයක් තිබේ නම් 409 ක් එම ගැටුම විස්තර කරයි) .

— සිනෙස්ටෙටික්
source
පිරිවිතරයට අනුව, 409 දෝෂය POSTඉල්ලීමකින් ආපසු ලබා දිය නොහැකි බව අඟවයි (නිවැරදිව භාවිතා කරන විට), එය සඳහන් කරන්නේ ඉලක්කගත සම්පත සමඟ ගැටෙන විට එය ආපසු ලබා දිය යුතු බවයි . ඉලක්කගත සම්පත තවම පළ කර නොමැති බැවින් එයට ගැටුම් ඇති විය නොහැකි අතර ඒ අනුව පිළිතුරු 409 Conflictදීම අර්ථවත් නොවේ.
— ග්‍රාන්ට් ග්‍රික්සන්
විවාදාත්මක ඉමෝ. ඔබ / පරිශීලකයින්ට තැපැල් කරන්නේ නම් සම්පත යනු තනි වාර්තාව / පරිශීලකයින් / {id} වෙනුවට එකතුවකි
— Sinaesthetic
ගබඩා කර ඇති සම්පතේ අනුවාදය සහ ඉල්ලූ සම්පතේ අනුවාදය අතර ගැටුමක් ඇති විට එය අනුවාද පාලනය සඳහා විශේෂයෙන් දෝෂයකි. එම අරමුණු සඳහා එය ඉතා ප්‍රයෝජනවත් වේ, නිදසුනක් ලෙස සේවාදායකයා සම්පතේ පැරණි අනුවාදයක් හැඹිලි කර එම වැරදි අනුවාදය මත පදනම්ව ඉල්ලීමක් යවන අතර එය තවදුරටත් කොන්දේසි සහිතව වලංගු නොවේ. "මෙම අවස්ථාවේ දී, ප්‍රතිචාර නිරූපණයේ ප්‍රතිශෝධන ඉතිහාසය මත පදනම්ව වෙනස්කම් ඒකාබද්ධ කිරීම සඳහා ප්‍රයෝජනවත් තොරතුරු අඩංගු විය හැකිය."
— ග්‍රාන්ට් ග්‍රික්සන්
මම ඔබේ යෝජනාවට කැමතියි PUT.
— ග්‍රාන්ට් ග්‍රිසන්
4

තවත් විභව ප්‍රතිකාරයක් වන්නේ සියල්ලට පසු පැච් භාවිතා කිරීමයි. පැච් එකක් යනු අභ්‍යන්තර තත්වය වෙනස් කරන සහ එකතු කිරීමට පමණක් සීමා නොවන දෙයක් ලෙස අර්ථ දැක්වේ.

පැච් මඟින් දැනටමත් පවතින අයිතම යාවත්කාලීන කිරීමට ඉඩ දීමෙන් ගැටළුව විසඳනු ඇත. බලන්න: RFC 5789: පැච්

— මාටින් කර්ස්ටන්
source
2
පැච් එක PUT වගේ නමුත් සම්පූර්ණ ආදේශකයක් නොවේ. සම්පතෙහි සමස්ත අංගයක් ප්‍රතිස්ථාපනය කරනවා වෙනුවට එක් අංගයක් එකතු කිරීම, ඉවත් කිරීම හෝ වෙනස් කිරීම වැනි සම්පත් කොටසක් වෙනස් කිරීමට එය භාවිතා කරයි.
— සිනෙස්ටෙටික්
3

ඔබේ නඩුවේදී ඔබට භාවිතා කළ හැකිය 409 Conflict

ඔබට HTTPsපහත ලැයිස්තුවෙන් වෙනත් තත්ව කේත පරීක්ෂා කිරීමට අවශ්‍ය නම්

1 ×---- තොරතුරු

100 Continue
101 Switching Protocols
102 Processing

2 ×---- සාර්ථකයි

200 OK
201 Created
202 Accepted
203 Non-authoritative Information
204 No Content
205 Reset Content
206 Partial Content
207 Multi-Status
208 Already Reported
226 IM Used

3 ×---- යළි හරවා යැවීම

300 Multiple Choices
301 Moved Permanently
302 Found
303 See Other
304 Not Modified
305 Use Proxy
307 Temporary Redirect
308 Permanent Redirect

4 ×---- සේවාදායක දෝෂයකි

400 Bad Request
401 Unauthorized
402 Payment Required
403 Forbidden
404 Not Found
405 Method Not Allowed
406 Not Acceptable
407 Proxy Authentication Required
408 Request Timeout
409 Conflict
410 Gone
411 Length Required
412 Precondition Failed
413 Payload Too Large
414 Request-URI Too Long
415 Unsupported Media Type
416 Requested Range Not Satisfiable
417 Expectation Failed
418 I’m a teapot
421 Misdirected Request
422 Unprocessable Entity
423 Locked
424 Failed Dependency
426 Upgrade Required
428 Precondition Required
429 Too Many Requests
431 Request Header Fields Too Large
444 Connection Closed Without Response
451 Unavailable For Legal Reasons
499 Client Closed Request

5 ×---- සේවාදායක දෝෂයකි

500 Internal Server Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
505 HTTP Version Not Supported
506 Variant Also Negotiates
507 Insufficient Storage
508 Loop Detected
510 Not Extended
511 Network Authentication Required
599 Network Connect Timeout Error
— අබ්දුල් අබුගසාලේ
source
1
wnwillo ඔබටත් ස්තූතියි.
— අබ්දු අබුගසාලේ
2

අනුපිටපත් වාර්තා සඳහා නිවැරදි කේතයක් පරික්ෂා කිරීමේදී මෙම ප්‍රශ්නයට බාධා ඇති විය.

මගේ නොදැනුවත්කමට සමාව දෙන්න, නමුත් සෑම කෙනෙකුම "300" කේතය නොසලකා හරින්නේ මන්දැයි මට තේරෙන්නේ නැත.

මගේ මතය අනුව මෙය ඔබේම භාවිතය සඳහා සම්මත නොවන හෝ විශේෂිත පද්ධතියක් තැනීම සඳහා පරිපූර්ණ කේතය වනු ඇත. මමත් වැරදියි!

https://tools.ietf.org/html/rfc7231#section-6.4.1

— හිටින්
source
මගේ අවබෝධය: "තත්ව කේතයෙන් දැක්වෙන්නේ ඉලක්ක සම්පතට එකකට වඩා නියෝජනය ඇති බවයි ... විකල්ප පිළිබඳ තොරතුරු සපයනු ලබන අතර එමඟින් පරිශීලකයාට (හෝ පරිශීලක නියෝජිතයාට) ඉල්ලීම එකක් හෝ වැඩි ගණනක් වෙත හරවා යැවීමෙන් කැමති නිරූපණයක් තෝරා ගත හැකිය. හඳුනාගැනීම් "අපි පැහැදිලිවම එකකට වඩා නියෝජනය වැළැක්වීමට උත්සාහ කරමු. විකල්ප නොමැත. සේවාදායකයාට තෝරා ගැනීමට විකල්ප නොමැත. සේවාදායකයා වෙනත් හැඳුනුම්පතක් සමඟ නැවත ඉදිරිපත් කළ යුතුය. ඒ සමඟම, සේවාදායකයාට එදිරිව සේවාදායකය තුළ අද්විතීය අයිඩී ජනනය කළ යුතුද යන්න සලකා බැලිය යුතුය.
— musicin3d
අර්ථාන්විතව, සේවාදායකයා "මෙය සාදන්න" යැයි පවසන අතර සේවාදායකයා ප්‍රතිචාර දක්වන්නේ "ඒ වෙනුවට මෙතැනට යන්න" යනුවෙනි. සංවාදය කිසිදු තේරුමක් නැත. එය සේවාදායකයා සේවාදායකයාට "ඒ වෙනුවට මෙම ස්ථානයට තැපැල් කරන්න" යැයි පවසනවා හා සමානයි. 300s යනු GET ඉල්ලීමකට හෝ POST ට වඩා උචිත ප්‍රතිචාරයක් වන අතර සේවාදායකයා "හරි මම එය නිර්මාණය කළෙමි, එය මෙහි අවසන් වී ඇත" යනුවෙන්
— ප්‍රතිචාර දක්වයි
2

බොහෝ දුරට එය එසේ ය 400 Bad Request

6.5.1. 400 නරක ඉල්ලීම


400 (නරක ඉල්ලීම) තත්ව කේතය මඟින් සේවාදායක දෝෂයක් ලෙස පෙනෙන දෙයක් නිසා සේවාදායකයාට ඉල්ලීම ක්‍රියාවට නැංවිය නොහැකි හෝ ක්‍රියා නොකරන බව පෙන්නුම් කරයි (උදා: විකෘති ඉල්ලීම් වාක්‍ය ඛණ්ඩය, අවලංගු ඉල්ලීම් පණිවිඩ සැකසීම හෝ රැවටිලිකාර ඉල්ලීම් මාර්ගගත කිරීම).

ඉල්ලීමෙහි අනුපිටපත් අගය (දැනටමත් පවතින අගය) අඩංගු බැවින් එය සේවාදායක දෝෂයක් ලෙස වටහා ගත හැකිය. ඊළඟ උත්සාහයට පෙර ඉල්ලීම වෙනස් කිරීමට අවශ්‍යය.
මෙම කරුණු සලකා බැලීමෙන් අපට HTTP STATUS 400 නරක ඉල්ලීම ලෙස නිගමනය කළ හැකිය.

— මොහොමඩ් සෆීර්
source
1
නරක ඉල්ලීම යනු පැකට්ටුවේ වාක්‍ය ඛණ්ඩය සමඟ ආවේනික ගැටළුවක් ඇති බවයි. වෙනත් සන්දර්භයක (සම්පත දැනටමත් නොපවතින) පැකට්ටුව සාර්ථක වුවහොත් එය 400 දෝෂය නැවත ලබා නොදිය යුතුය.
— ග්‍රාන්ට් ග්‍රික්සන්
1

208 ගැන කුමක් කිව හැකිද - http://httpstatusdogs.com/208-already-reported ? එය විකල්පයක් ද?

මගේ මතය අනුව, එකම දෙය පුනරාවර්තන සම්පතක් නම් කිසිදු දෝෂයක් මතු නොවිය යුතුය. සියල්ලට පසු, සේවාදායකයාගේ හෝ සේවාදායකයේ කිසිදු දෝෂයක් නොමැත.

— ප්‍රනාන්දු ෆෙරෙයිරා
source
දැනටමත් පවතින හැඳුනුම්පතක් එකතු කිරීමට ඔබට අවශ්‍ය නිසා මෙය විකල්පයක් නොවේ. එබැවින් ඔබ යමක් එකතු කිරීමට උත්සාහ කරන නමුත් මෙය දැනටමත් තිබේ. හරි අදාළ වන්නේ දත්ත කට්ටලය වැඩී ඇත්නම් පමණි. යමක් එකතු කරන්න -> හරි මම කිසිවක් එකතු කළේ නැහැ. නොගැලපේ, මම හිතන්නේ.
— මාටින් කර්ස්ටන්
මම කී පරිදි, මෙය දෝෂයක් යැයි මම නොසිතමි. නමුත් මාටින්ගේ කාරණය මට පෙනේ
— ප්‍රනාන්දු
සම්පත සාර්ථකව නිර්මාණය කර නොමැති නම්, අර්ථ දැක්වීම අනුව දෝෂයක් ඇත.
— ග්‍රාන්ට් ග්‍රික්සන්
දත්ත එකතු කිරීම සඳහා POST ද භාවිතා වේ. මෙය නිර්වචනය අනුව මිස දෝෂයක් නොවේ .
— සන්කැට් 2000
@ Suncat2000 එය එසේ වුවද, දත්ත සාර්ථකව එකතු නොකළේ නම්, තවමත් දෝෂයක් පවතී. සම්පත දැනටමත් තිබේ නම්, කිසිදු දත්තයක් එකතු නොවේ.
— ග්‍රාන්ට් ග්‍රික්සාන්
1

202 පිළිගන්නේ නැත්තේ ඇයි ? එය හරි ඉල්ලීමක් (200s), සේවාදායක දෝෂ (400s) නොතිබුණි.

තත්ව කේත අර්ථ දැක්වීම් 10 සිට :

"202 පිළිගෙන ඇත. සැකසීම සඳහා ඉල්ලීම පිළිගෙන ඇත, නමුත් සැකසීම සම්පූර්ණ කර නොමැත."

... එය සම්පූර්ණ කිරීමට අවශ්‍ය නොවූ නිසා, එය දැනටමත් පැවතුන නිසා. සේවාදායකයා එය දැනටමත් පවතින බව නොදනී, ඔවුන් කිසි වරදක් කර නැත.

මම නැඹුරු වන්නේ 202 ක් විසි කිරීමට සහ GET නැවත ලැබීමට තිබූ දේට සමාන අන්තර්ගතයක් /{resource}/{id}නැවත ලබා දීමට ය.

— පිලිප් හැරින්ග්ටන්
source
23
මෙම පිළිතුර වැරදිය. 202 යන්නෙන් අදහස් කරන්නේ සේවාදායකයා ඉල්ලීම සමඟ ගැටළුවක් සොයා නොගත් නමුත් ප්‍රතිචාර දැක්වීමෙන් පසු ඉල්ලීම ක්‍රියාවට නැංවීමට තෝරා ගත් බවයි. සැකසුම් සාර්ථක වනු ඇතැයි එය අපේක්ෂා කරන බව ද එයින් අදහස් වේ. අපගේ නඩුවේදී සේවාදායකයා දන්නවා සැකසුම් අසාර්ථක වන බව, එබැවින් 202 වැරදි ප්‍රතිචාරයකි.
— ඒඩ්‍රියන්
4
202 සඳහා උදාහරණයක් වනුයේ පෝලිම් හෝ දායකත්වයයි. වෙනත් වචන වලින් කිවහොත්, ඔබ මේ මොහොතේම එය විමසීමට නම් ඉල්ලීමේ ප්‍රති result ලය වහාම ලබා ගත නොහැක.
— සිනෙස්ටෙටික්
1
සේවාදායකයා තවමත් ඉල්ලීම සකසන්නේ නම් මෙය සුදුසු වේ. 200 හෝ 204 වඩාත් සුලභ වනු ඇත. OP විසින් උපග්‍රන්ථ ඉල්ලීමක් කරන බැවින්, වස්තුවෙහි පැවැත්ම අපේක්ෂිත කොන්දේසියක් මිස දෝෂයක් නොවේ.
— සන්කැට් 2000
ඉල්ලීම පිළිගත් බව සේවාදායකයාට පැවසීමේ තේරුමක් නැත, මන්ද එය එසේ නොවන බව ඔබ දැනටමත් දන්නා බැවිනි!
— lucastamoios
1
D ඒඩ්‍රියන් සහ ලුකාස්ටාමොයිස් ප්‍රතිචාරය දැක්වීමට පෙර ඔබ දෙදෙනාම සේවාදායකයා දත්ත සමුදායෙන් සමකාලීනව කියවන බව උපකල්පනය කරයි. මෙය සැමවිටම එසේ නොවේ, එබැවින් මෙම පිළිතුර "වැරදි" නොවේ, මන්ද සේවාදායකයා සෑම විටම පවතින වාර්තාව ගැන "නොදන්නා" බැවිනි. අසමමුහුර්ත පද්ධතිවල මෙය බොහෝ සෙයින් සිදුවේ, පසුබිම් සේවකයින් විසින් සැකසීම සඳහා වන ඉල්ලීම් api ස්තරය සරලව සටහන් කරයි.
— gsaslis
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.