සෙවුම් RESTful අතුරුමුහුණතකට ගැලපෙන්නේ කෙසේද?

155

RESTful අතුරුමුහුණතක් නිර්මාණය කිරීමේදී, ඉල්ලීම් වර්ගවල අර්ථ නිරූපණය සැලසුමට අත්‍යවශ්‍ය යැයි සැලකේ.

GET - ලැයිස්තු එකතු කිරීම හෝ මූලද්‍රව්‍යය ලබා ගැනීම
PUT - එකතු කිරීම හෝ මූලද්රව්යය ප්රතිස්ථාපනය කරන්න
POST - එකතු කිරීම හෝ මූලද්රව්යය සාදන්න
Delete - හොඳයි, erm, delete රැස් කිරීම හෝ අංගයක්

කෙසේ වෙතත්, මෙය "සෙවීම" යන සංකල්පය ආවරණය කරන බවක් නොපෙනේ.

උදා: රැකියා සෙවුම් වෙබ් අඩවියකට සහාය වන වෙබ් සේවා කට්ටලයක් සැලසුම් කිරීමේදී ඔබට පහත සඳහන් අවශ්‍යතා තිබිය හැකිය:

තනි රැකියා දැන්වීමක් ලබා ගන්න
- ලබා ගන්න කිරීමටdomain/Job/{id}/
රැකියා දැන්වීමක් සාදන්න
- වෙත තැපැල් කරන්නdomain/Job/
රැකියා දැන්වීම යාවත්කාලීන කරන්න
- PUT සිටdomain/Job/
රැකියා දැන්වීම මකන්න
- Delete කිරීමටdomain/Job/

"සියලු රැකියා ලබා ගන්න" ද සරල ය:

ලබා ගන්න කිරීමටdomain/Jobs/

කෙසේ වෙතත්, රැකියාව "සෙවීම" මෙම ව්‍යුහයට වැටෙන්නේ කෙසේද?

එය "ලැයිස්තු එකතු කිරීමේ" විචල්‍යතාවයක් යැයි ඔබට පැවසිය හැකිය .

ලබා ගන්න කිරීමටdomain/Jobs/

කෙසේ වෙතත්, සෙවීම් හැකි සංකීර්ණ විය යුතු අතර එය දිගු ලබා ගන්න string ජනනය කරන ලද සෝදිසි නිෂ්පාදනය කිරීමට සම්පූර්ණයෙන්ම හැකි ය. එනම්, මෙහි SO ප්‍රශ්නයක් යොමු කිරීමේදී , අක්ෂර 2000 ට වඩා දිගු GET නූල් භාවිතා කිරීමේ ගැටළු තිබේ.

නිදසුනක් මුහුණේ සෙවුමක විය හැකිය - "රැකියා" උදාහරණය දිගටම කරගෙන යාම.

"තාක්‍ෂණය", "රැකියා මාතෘකාව", "විනය" මෙන්ම නිදහස්-පෙළ වචන, රැකියාවේ වයස, ස්ථානය සහ වැටුප යන අංශ සෙවීමට මට ඉඩ දිය හැකිය.

තරල පරිශීලක අතුරුමුහුණතක් සහ තාක්‍ෂණයන් සහ රැකියා මාතෘකා විශාල සංඛ්‍යාවක් සමඟින්, සෙවුමකට මුහුණු තේරීම් විශාල සංඛ්‍යාවක් ඇතුළත් විය හැකිය.

මෙම උදාහරණය රැකියා වලට වඩා CV වලට වෙනස් කරන්න, ඊටත් වඩා පැතිකඩයන් ගෙන එනු ඇති අතර, තෝරාගත් පැතිකඩ සියයක් සහිත සෙවුමක් ඔබට පහසුවෙන්ම සිතාගත හැකිය, නැතහොත් අක්ෂර 40 ක් පමණක් ඇති අක්ෂර 50 ක් දිග (උදා: රැකියා මාතෘකා, විශ්ව විද්‍යාල නම්, සේවා යෝජකයාගේ නම්).

එවැනි තත්වයක් තුළ සෙවුම් දත්ත නිවැරදිව යවනු ඇති බව සහතික කිරීම සඳහා PUT හෝ POST ගෙනයාම යෝග්‍ය වේ. උදා:

වෙත තැපැල් කරන්නdomain/Jobs/

නමුත් අර්ථාන්විතව එය එකතුවක් නිර්මාණය කිරීම සඳහා උපදෙස් වේ.

ඔබ විය හැකි ද ඔබට සෙවුම් නිර්මාණය ලෙස මෙම අදහස් ප්රකාශ කරන්නම් කියන්න:

වෙත තැපැල් කරන්නdomain/Jobs/Search/

හෝ (පහත පිළිස්සීම් මඟින් යෝජනා කර ඇති පරිදි)

වෙත තැපැල් කරන්නdomain/JobSearch/

අර්ථාන්විතව එය අර්ථවත් බවක් පෙනෙන්නට තිබුණත් ඔබ ඇත්ත වශයෙන්ම කිසිවක් නිර්මාණය නොකරයි, ඔබ දත්ත සඳහා ඉල්ලීමක් කරයි.

එබැවින්, අර්ථාන්විතව එය GET ය , නමුත් ඔබට අවශ්‍ය දේ සඳහා GET සහතික නොවේ.

ඉතින්, ප්‍රශ්නය නම් - හැකි තාක් දුරට රෙස්ට්ෆුල් නිර්මාණයට සත්‍ය ලෙස තබා ගැනීමට උත්සාහ කිරීම, මම HTTP හි සීමාවන් තුළ තබා ඇති බව සහතික කරමින්, සෙවීමක් සඳහා වඩාත් සුදුසු නිර්මාණය කුමක්ද?

— රොබ් බේලි
source

3

මම බොහෝ විට GET භාවිතා කිරීමට අදහස් කරමි domain/Jobs?keyword={keyword}. මෙය මට හොඳින් ක්‍රියාත්මක වේ :) මගේ බලාපොරොත්තුව නම් ක්‍රියා SEARCHපදය ප්‍රමිතියක් බවට පත්වනු ඇති බවයි. programmmers.stackexchange.com/questions/233158/…

— Knerd

ඔව්, සුළු උදාහරණයකට ගැටලුවක් නොමැති බව මට පෙනේ. නමුත් අප ගොඩනඟන මෙවලමෙහි ඇත්ත වශයෙන්ම එය විශ්වාස කළ නොහැකි තරම් සංකීර්ණ සෙවුමකින් අවසන් වන අතර එහි ප්‍රති results ලය වන්නේ අක්ෂර 2000 ට වඩා දිගු GET නූලකි. එසේනම් කුමක් ද?

— රොබ් බේලි

ඇත්තටම ඉතා හොඳ කරුණක්. සම්පීඩන තාක්ෂණයක් නියම කිරීම ගැන කුමක් කිව හැකිද?

— Knerd

3

ශරීරයක් සමඟ GET ලබා ගැනීමට HTTP පිරිවිතරයට අවසර ඇත, මිඩ්ල්වෙයාර් (සමහර විට එසේ නොවේ);) හෝ සහාය නොදක්වයි. මෙය වරින් වර Stackexchange හි පැමිණේ. stackoverflow.com/questions/978061/http-get-with-request-body

— Rob

3

මම අවසන් කළේ POST JobSearch මගින් සත්‍ය සෙවුම් ආයතනයක් නිර්මාණය කර රැකියා සෙවුමක් ලබා දීමයි. එවිට රැකියා ලබා ගන්න? JobSearch = jobSearchId මගින් සැබෑ රැකියා එකතුව ලබා දෙයි.

— සෙරාඩ්

109

GET ඉල්ලීම් වෙනත් විසඳුම් වලට වඩා උසස් වාසි ඇති බව ඔබ අමතක නොකළ යුතුය :

1) GET ඉල්ලීම් URL තීරුවෙන් පිටපත් කළ හැකිය, ඒවා සෙවුම් යන්ත්‍ර මගින් ජීර්ණය කරනු ලැබේ, ඒවා “මිත්‍රශීලී” වේ. “මිත්‍රශීලී” යන්නෙන් අදහස් කරන්නේ සාමාන්‍යයෙන් GET ඉල්ලීමක් ඔබගේ යෙදුම තුළ කිසිවක් වෙනස් නොකළ යුතු බවයි (idempotent) . සෙවීම සඳහා සම්මත අවස්ථාව මෙයයි.

2) මෙම සංකල්ප සියල්ලම පරිශීලකයාගෙන් සහ සෙවුම් යන්ත්‍රයෙන් පමණක් නොව වාස්තු විද්‍යාත්මක, API සැලසුම් දෘෂ්ටි කෝණයෙන් ඉතා වැදගත් වේ.

3) ඔබ නිර්මාණය නම් සලසන වක් මගක් සමග තැපැල් / මරලා ඔබ හරි, දැන් කල්පනා නොවන ගැටලු ඇති වනු ඇත. උදාහරණයක් ලෙස බ්‍රව්සරයක සැරිසැරීමේ පිටුපස බොත්තම / පිටුව / ඉතිහාසය නැවුම් කරන්න. මේවා ඇත්ත වශයෙන්ම විසඳිය හැකිය, නමුත් එය තවත් ක්‍රියාමාර්ගයක් වනු ඇත, පසුව තවත් එකක් ...

මේ සියල්ල සැලකිල්ලට ගනිමින් මගේ අවවාදය වනුයේ:

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

b) ජොබ් සෙවුම වැනි ඔබේ යෙදුමේ වෙනත් ආයතනයක් සාදන්න . ඔබට බොහෝ විකල්ප තිබේ යැයි උපකල්පනය කළහොත්, මෙම සෙවුම් ගබඩා කර ඒවා කළමනාකරණය කිරීමට ඔබට අවශ්‍ය වනු ඇත, එබැවින් එය ඔබගේ යෙදුම නිරවුල් කරයි. ඔබට ජොබ් සෙවුම් වස්තු සමඟ සමස්ත ආයතනයක් ලෙස වැඩ කළ හැකිය , එයින් අදහස් කරන්නේ ඔබට එය පරීක්ෂා කිරීමට / පහසුවෙන් භාවිතා කළ හැකි බවයි.

පුද්ගලිකව මම මගේ නියපොතු සමඟ සටන් කිරීමට උත්සාහ කරමි. අ) සහ සියලු බලාපොරොත්තු නැති වූ විට, මගේ ඇස්වල කඳුළු පුරවාගෙන ආ විකල්පය වෙත ආපසු යන්නෙමි .

— p1100i
source

4

පැහැදිලි කිරීම සඳහා, මෙම ප්‍රශ්නය වෙබ් අඩවි නිර්මාණය ගැන නොව වෙබ් සේවා සැලසුම ගැන අදහස් කෙරේ. එබැවින් බ්රවුසරයේ හැසිරීම ප්රශ්නයේ අර්ථ නිරූපනයේ පුළුල් විෂය පථය කෙරෙහි උනන්දුවක් දක්වන අතර, විශේෂයෙන් විස්තර කර ඇති පරිදි එය කිසිදු ප්රතිවිපාකයක් නොමැත. (සිත්ගන්නා කරුණ වුවද).

— රොබ් බේලි

@RobBaillie ඔව් බ්‍රව්සරය භාවිතා කිරීමේ අවස්ථාවකි. සමස්තයක් ලෙස ඔබගේ සෙවීම URL නූලකින් නිරූපණය වන බව ප්‍රකාශ කිරීමට මට අවශ්‍ය විය. පසුකාලීනව පිළිතුරේ ඇති වෙනත් කරුණු සමඟ භාවිතයේ විශාල සැනසීමක් ඇති.

— p1100i

B ලක්ෂ්‍යයේදී, මෙය POST වෙත මා විසින්ම යොමු කරන ලද සරල විචලනයකි domain/Jobs/Search/, සමහර විට domain/JobsSearch/ඒ වෙනුවට, හෝ ඔබ අදහස් කළේ වෙනස් දෙයක්ද? ඔබට පැහැදිලි කළ හැකිද?

— රොබ් බේලි

10

විසඳුමේ කොටසක් නොව REST බොහෝ විට ගැටලුවේ කොටසක් යැයි මට හැඟෙන්නේ ඇයි?

— ජෙන්ස්

2

"GET ඉල්ලීම ඔබගේ යෙදුම තුළ කිසිවක් වෙනස් නොකළ යුතුය (idempotent)" GET idempotent වන අතර, අදාළ වචනය මෙහි " ආරක්ෂිත " වේ. Idempotent යන්නෙන් අදහස් කරන්නේ සම්පතක් මත GET කිරීම දෙවරක් එම සම්පත මත GET කිරීම හා සමාන බවයි. PUT ද නිරර්ථක ය, නමුත් ආරක්ෂිත නොවේ.

— ජස්මිජන්

13

TL; DR: පෙරීම සඳහා GET, සෙවීම සඳහා POST

සංකීර්ණ සෙවුමකට එදිරිව එකතුවක් ලැයිස්තුගත කිරීමෙන් ප්‍රති results ල පෙරීම අතර වෙනසක් මම කරමි. මා භාවිතා කරන ලිට්මස් පරීක්ෂණය මූලික වශයෙන් මට පෙරීමට වඩා වැඩි යමක් අවශ්‍ය නම් (ධනාත්මක, negative ණ හෝ පරාසය) POST අවශ්‍ය වන වඩාත් සංකීර්ණ සෙවුමක් ලෙස මම සලකමි.

ආපසු ලැබෙන්නේ කුමක් ද යන්න ගැන සිතන විට මෙය ශක්තිමත් වේ. මම සාමාන්‍යයෙන් GET භාවිතා කරන්නේ සම්පතකට බොහෝ දුරට සම්පූර්ණ ජීවන චක්‍රයක් තිබේ නම් පමණි (PUT, DELETE, GET, එකතුව GET) . සාමාන්‍යයෙන් එකතුවක GET මම එම එකතුව සෑදෙන REST සම්පත් වන URI ලැයිස්තුවක් නැවත ලබා දෙමි. සංකීර්ණ විමසුමක දී ප්‍රතිචාරය ගොඩනැගීම සඳහා මම බහු සම්පත් වලින් ඇදගෙන යනු ඇත (SQL එක්වන්න යැයි සිතන්න) එබැවින් මම යූආර්අයි ආපසු එවන්නේ නැත, නමුත් සත්‍ය දත්ත. ගැටළුව වන්නේ දත්ත සම්පතක් තුළ නිරූපණය නොකිරීමයි, එබැවින් මට සෑම විටම දත්ත ආපසු ලබා දීමට සිදුවේ. මෙය මට POST අවශ්‍ය බවට පැහැදිලි කප්පාදුවක් ලෙස පෙනේ.

-

එය ටික වේලාවක් ගත වී ඇති අතර මගේ මුල් පෝස්ට් එක ටිකක් අලස නිසා මම යාවත්කාලීන කරනු ඇතැයි සිතුවෙමි.

GET යනු බොහෝ වර්ගවල දත්ත, REST සම්පත් එකතු කිරීම, සම්පතක ව්‍යුහාත්මක දත්ත, තනි ගෙවීම් (රූප, ලියකියවිලි ආදිය) ආපසු ලබා දීම සඳහා වන තේරීමකි.

POST යනු GET, PUT, DELETE යනාදිය යටතේ නොගැලපෙන ඕනෑම දෙයකට කැචල් ක්‍රමයයි.

මෙම අවස්ථාවේදී මම සිතන්නේ සරල සෙවීම්, පෙරීම GET හරහා සිතාමතාම අර්ථවත් කරයි. සංකීර්ණ සෙවීම් පුද්ගලික මනාපයන් මත වේ, විශේෂයෙන් ඔබ සමුච්චිත කාර්යයන්, හරස් සහසම්බන්ධතා (එක්වීම), නැවත හැඩතල ගැන්වීම් යනාදියෙහි යෙදී සිටී නම්. ) බොහෝ විට POST ඉල්ලීම් ආයතනයක් ලෙස වඩාත් අර්ථවත් කළ හැකිය.

ඒපීඅයි භාවිතයේ අත්දැකීම් අංශය ද මම සලකා බලමි. මට සාමාන්‍යයෙන් අවශ්‍ය වන්නේ බොහෝ ක්‍රම භාවිතා කිරීමට පහසු සහ බුද්ධිමත් ලෙස සකසා ගැනීමයි. මම වඩාත් නම්‍යශීලී (එබැවින් වඩාත් සංකීර්ණ) ඇමතුම් POST වලට සහ වෙනත් සම්පත් යූආර්අයි වෙත තල්ලු කරමි, විශේෂයෙන් එකම ඒපීඅයි හි අනෙකුත් REST සම්පත් වල හැසිරීමට නොගැලපේ නම්.

කෙසේ හෝ වේවා, ඔබ GET හෝ POST හි සෙවීමක් කරන්නේද යන්නට වඩා අනුකූලතාව වැදගත් වේ.

මෙය උපකාරී වේ යැයි සිතමි.

— dietbuddha
source

1

REST යන්නෙන් අදහස් කෙරෙනුයේ යටින් ක්‍රියාත්මක කිරීම වියුක්ත කිරීමයි (උදා - සම්පතක් යනු දත්ත සමුදායක පේළියක් හෝ දෘ hard තැටියක ඇති ගොනුවක් නොවේ, නමුත් ඕනෑම දෙයක් විය හැකිය ) POST නැවත භාවිතා කිරීම අර්ථවත් බව මම නොදනිමි SQL සම්බන්ධ වීම සිදු වන විට ලබා ගන්න. ඔබට පාසල් මේසයක් හා ළමා මේසයක් ඇති අතර ඔබට පන්තියක් අවශ්‍ය යැයි සිතමු (එක් පාසලක්, බහු දරුවන්). ඔබට පහසුවෙන් අතථ්‍ය සම්පතක් නිර්වචනය කළ හැකිය GET /class?queryParams. පරිශීලකයෙකුගේ දෘෂ්ටි කෝණයෙන් "පන්තිය" සැමවිටම දෙයක් වන අතර ඔබට කිසිදු අමුතු SQL සම්බන්ධතාවයක් කිරීමට අවශ්‍ය නොවීය.

— stevendesu

"පෙරීම" සහ "සෙවීම" අතර වෙනසක් නැත.

— නිකලස් ෂෑන්ක්ස්

1

ඔව් ඇත, පෙරනයක් පවත්නා ක්ෂේත්‍ර මත පදනම් වේ. සෙවුමක වඩාත් සංකීර්ණ රටා, ක්ෂේත්‍ර ඒකාබද්ධ කිරීම, යාබද අගයන් ගණනය කිරීම යනාදිය අඩංගු විය හැකිය

— user13796

@stevendesu හරියටම, ඒ නිසා මම දෙකටම POST භාවිතා කරමි (සෙවුමක් නිර්මාණය කිරීම) :-)

— ymajoros

maymajoros ඔබ සෙවුම් පද සහ සෙවුම් ප්‍රති results ල කොහේ හරි සුරකිනවා නම්, POST අර්ථවත් ලෙස අර්ථවත් වන බව මම නොදනිමි. ඔබ සෙවීමක් සිදුකරන විට ඔබ තොරතුරු සඳහා ඉල්ලීමක් කරන විට, ඔබ කොතැනකවත් රඳවා තබා ගැනීමට නව තොරතුරු සපයන්නේ නැත.

— stevendesu

10

REST හි සම්පත් අර්ථ දැක්වීම ඉතා පුළුල් ය. කෙසේ වෙතත් ඇත්ත වශයෙන්ම ඔබට සමහර දත්ත එකතු කිරීමට අවශ්‍යය.

සෙවුම් සම්පතක් එකතු කිරීමේ සම්පතක් ලෙස සිතීම ප්‍රයෝජනවත් වේ. විමසුම් පරාමිතීන්, සමහර විට යූආර්අයි හි සෙවිය හැකි කොටස ලෙස හැඳින්වේ, සේවාදායකයා උනන්දුවක් දක්වන අයිතම වෙත සම්පත් පටු කරයි.

උදාහරණයක් ලෙස, ප්‍රධාන ගූගල් යූආර්අයි "අන්තර්ජාලයේ සෑම වෙබ් අඩවියකටම සබැඳි" එකතු කිරීමේ සම්පතක් වෙත යොමු කරයි. විමසුම් පරාමිතීන් ඔබට දැකීමට අවශ්‍ය අඩවි වලට පටු වේ.

(URI = විශ්ව සම්පත් හදුනා ගැනීම, එහි URL = විශ්ව සම්පත් ලොකේටරය, එහිදී හුරුපුරුදු "http: //" යනු URI සඳහා පෙරනිමි ආකෘතියයි. එබැවින් URL යනු ස්ථානගත කිරීමකි, නමුත් REST හි එය සම්පත් හඳුනාගැනීමක් සඳහා සාමාන්‍යකරණය කිරීම හොඳය. මිනිසුන් ඒවා එකිනෙකට හුවමාරු කර ගත හැකි වුවත් භාවිතා කරයි.)

ඔබේ උදාහරණයේ ඔබ සොයන සම්පත රැකියා එකතුව බැවින්, සෙවීම අර්ථවත් කරයි

වෙබ් අඩවිය / රැකියා ලබා ගන්න? Type = blah & location = here & etc = etc

(ආපසු) {රැකියා: [{රැකියාව: ...}]}

ඉන්පසු එම එකතුවට නව අයිතම එකතු කිරීම සඳහා උපග්‍රන්ථය හෝ ක්‍රියාවලි ක්‍රියා පදය වන POST භාවිතා කරන්න:

පෝස්ට් අඩවිය / රැකියා

{රැකියා: ...}

jobසෑම අවස්ථාවකම එය වස්තුව සඳහා එකම ව්‍යුහයක් බව සලකන්න . සේවාදායකයෙකුට රැකියා එකතුවක් ලබා ගත හැකි අතර, සෙවුම් පටු කිරීම සඳහා විමසුම් පරාමිතීන් භාවිතා කර, පසුව නව අයිතමයක් පළ කිරීම සඳහා එක් අයිතමයක් සඳහා එකම ආකෘතිය භාවිතා කරන්න. නැතහොත් එම අයිතමයන්ගෙන් එකක් ගෙන එය යාවත්කාලීන කිරීම සඳහා එහි යූආර්අයි වෙත ගෙන යා හැකිය.
සැබවින්ම දිගු හෝ සංකීර්ණ විමසුම් නූල් සඳහා, ඒ වෙනුවට POST ඉල්ලීම් ලෙස යැවීම සම්මුතියෙන් හරි ය. විමසුම් පරාමිතීන් නම / අගය යුගල ලෙස හෝ JSON හෝ XML ව්‍යුහයක කූඩු කළ වස්තු ලෙස එකතු කර ඉල්ලීමෙහි සිරුරට යවන්න. උදාහරණයක් ලෙස, ඔබේ විමසුමට නම / අගය යුගලයක් වෙනුවට කූඩු දත්ත තිබේ නම්. POST සඳහා වන HTTP පිරිවිතර එය උපග්‍රන්ථය හෝ ක්‍රියාවලි ක්‍රියා පදය ලෙස විස්තර කරයි. (ඔබට REST හි ඇති අඩුපාඩුවක් හරහා යුධ නැවක් යාත්‍රා කිරීමට අවශ්‍ය නම්, POST භාවිතා කරන්න.)

මම එය ආපසු හැරවීමේ සැලැස්ම ලෙස භාවිතා කරමි.

ඔබ එසේ කරන විට ඔබට අහිමි වන දේ අ) GET ශුන්‍යයි - එනම් එය කිසිවක් වෙනස් නොකරයි - POST නොවේ. එබැවින් ඇමතුම අසමත් වුවහොත්, මිඩ්ල්වෙයාර් ස්වයංක්‍රීයව නැවත උත්සාහ නොකරනු ඇත, සහ 2) ශරීරයේ සෙවුම් පරාමිතීන් සමඟ, ඔබට තවදුරටත් යූආර්අයි කපා ඇලවිය නොහැක. එනම්, යූආර්අයි ඔබට අවශ්‍ය සෙවීම සඳහා නිශ්චිත හඳුනාගැනීමක් නොවේ.

"සෙවීම" වෙතින් "සාදන්න" අතර වෙනස හඳුනා ගැනීම. REST භාවිතයට අනුකූල විකල්ප කිහිපයක් තිබේ:

රැකියා වෙනුවට රැකියා සෙවීම වැනි එකතුවේ නමට යමක් එකතු කිරීමෙන් ඔබට එය යූආර්අයි හි කළ හැකිය. එයින් අදහස් වන්නේ ඔබ සෙවුම් එකතුව වෙනම සම්පතක් ලෙස සලකන බවයි.
POST හි අර්ථ නිරූපණය උපග්‍රන්ථ හෝ ක්‍රියාවලියක් බැවින්, ඔබට ගෙවුම් භාරය සමඟ සෙවුම් ආයතන හඳුනාගත හැකිය. {රැකියාව: ...} එදිරිව. {සෙවීම: ...} වගේ. එය නිසි ලෙස පළ කිරීම හෝ සැකසීම POST තර්කනය සතු ය.

එය බොහෝ දුරට නිර්මාණ / ක්‍රියාත්මක කිරීමේ මනාපයකි. මම හිතන්නේ නැහැ පැහැදිලි සමුළුවක් තියෙනවා කියලා.

එබැවින්, ඔබ දැනටමත් සකස් කර ඇති පරිදි, අදහස වන්නේ එකතු කිරීමේ සම්පතක් නිර්වචනය කිරීමයි jobs

අඩවි / රැකියා

සෙවීම පටු කිරීම සඳහා GET + විමසුම් පරාමිතීන් සමඟ සොයන්න. දිගු හෝ ව්‍යුහාත්මක දත්ත විමසීම් POST හි සිරුරට යයි (සමහරවිට වෙනම සෙවුම් එකතුවකට). එකතුවට එකතු කිරීම සඳහා POST සමඟ සාදන්න. PUT සමඟ විශේෂිත URI වෙත යාවත්කාලීන කරන්න.

.

. පිළිතුර, මම එය යම් සම්මුතියක් හා පුහුණුවක් සහිතව තැබුවෙමි.)

— රොබ්
source

එය සිත්ගන්නා අදහසක් - වෙනස හඳුනා ගැනීම සඳහා ගෙවීම් භාරය භාවිතා කිරීම ගැන මම නොසිතමි. එය මඳක් යටින් පෙනේ! නමුත් මම හිතන්නේ යූආර්අයි යෝජනා ක්‍රමයේ ඇත්ත වශයෙන්ම කිසිදු ක්‍රියා පදයක් අඩංගු නොවේ - එය ක්‍රියා පදය නිර්වචනය කරන ඉල්ලීම් වර්ගයයි. සමහර විට ගෙවීම් යූආර්අයි වලට වඩා ඉල්ලීම් වර්ගයට අර්ථවත් වේ. එකම කනස්සල්ල - එය API භාවිතා කරන්නෙකුට විනිවිද පෙනෙන ද?

— රොබ් බේලි

ක්‍රියාත්මක කිරීම සම්බන්ධයෙන් (අපි භාවිතා කරන්නේ නෝඩ් සහ එක්ස්ප්‍රස්), එයින් අදහස් කරන්නේ routeසැකසුම් තේරීම සැබවින්ම හැසිරවිය නොහැකි බවයි. මට ඒ දෙස බැලිය යුතුයි ...

— රොබ් බේලි

මට එකම බඩවැල් හැඟීමක් ඇත, එය යූආර්අයි මගින් වෙන් කිරීම වඩා පිරිසිදු බව පෙනේ. මම නැවත නැවතත් ඉදිරියට යමි. එය විනිශ්චය කැඳවීමකි. කෙසේ වෙතත්, HTTP හි අර්ථ නිරූපණය මඟින් එය ශරීරයට දැමීමට ඉඩ දෙනු ඇත. මම කියන්න කැමතියි, REST ආදර්ශනය කර ඇත්තේ ලෝක ව්‍යාප්ත වෙබ් අඩවියෙන් වන අතර WWW ගොඩනගා ඇත්තේ GET සහ POST සමඟයි.

— රොබ්

8

මම සාමාන්‍යයෙන් OData විමසුම් භාවිතා කරමි, ඒවා GET ඇමතුමක් ලෙස ක්‍රියාත්මක වන නමුත් ආපසු ලබා දුන් දේපල සීමා කර පෙරහන් කිරීමට ඔබට ඉඩ සලසයි.

ඔබ වැනි ටෝකන භාවිතා කරන $select=අතර $filter=එමඟින් ඔබ යූආර්අයි සමඟ අවසන් වනු ඇත.

/users?$select=Id,Name$filter=endswith(Name, 'Smith')

ඔබ ද භාවිතා පිටු සැකසීම කළ හැකි $skipසහ $topසහ ඇණවුම්.

වැඩි විස්තර සඳහා OData.org බලන්න . ඔබ භාවිතා කරන්නේ කුමන භාෂාවද යන්න ඔබ විසින් නිශ්චිතව දක්වා නැත, නමුත් එය ASP.NET නම්, WebApi වේදිකාව OData විමසුම් සඳහා සහය දක්වයි - අනෙක් අයට (PHP යනාදිය) දත්ත සමුදා විමසුම් වලට පරිවර්තනය කිරීමට ඔබට භාවිතා කළ හැකි පුස්තකාල තිබේ.

— ට්‍රෙවර් පිල්ලේ
source

6

සිත්ගන්නා සබැඳියක් සහ බැලීම වටී, නමුත් එය විස්තර කර ඇති මූලික ගැටළුව විසඳන්නේද, GET ඉල්ලීම් විමසුම් දාමයේ අක්ෂර 2000 කට වඩා සහාය නොදක්වන අතර, විමසුම මෙයට වඩා දිගු විය හැකි බව මුළුමනින්ම කිව හැකිද?

— රොබ් බේලි

@RobBaillie එය තවමත් විමසුම් නූලක් සහිත GET ඇමතුමක් බැවින් මම නොසිතමි. වෙබ් දත්ත ප්‍රභවයන් විමසීමේ ප්‍රමිතියක් වන බැවින් ඔබට හැකි සෑම තැනකම ඔඩාටා භාවිතා කිරීමට මම යෝජනා කරමි. එමෙන්ම විමසුම ඉතා සංකීර්ණ විය යුතු වාර ගණනක් (ඇත්නම්) ඔබට එය 2000 අක්ෂර විමසුමකට නොගැලපෙන පරිදි නිශ්චිත එකක් සාදන්න. ඔබ වෙත ඇමතුමක් ලබා දෙන අන්ත ලක්ෂ්‍යය

— ට්‍රෙවර් පිල්ලේ

“ඔබට GET ඇමතුමක් ලබා දෙන නිශ්චිත අන්ත ලක්ෂ්‍යයක්” සඳහා ඔබේ ප්‍රවේශය පැහැදිලි කළ හැකිද? අවසාන ලක්ෂ්‍යය පෙනෙනු ඇතැයි ඔබ සිතන්නේ කෙසේද?

— රොබ් බේලි

@RobBaillie ෂුවර් - නැවතත් ඔබ භාවිතා කරන්නේ කුමන තාක්‍ෂණයදැයි මට විශ්වාස නැත, නමුත් ASP.NET හි මම නිශ්චිත පාලකයක් JobsNearMeAddedInTheLast7Daysහෝ ඔඩටා සඳහා දීර් / / සංකීර්ණ වූ විමසුම සංයුක්ත කිරීම සඳහා නිර්මාණය කරමි. .

— ට්‍රෙවර් පිල්ලේ

1

මට පේනවා. කකුල් කිහිපයක් ඇති තවත් සිත්ගන්නාසුලු සිතුවිල්ලක්, මෙය මගේ විශේෂිත අවස්ථාව සඳහා උපකාරී වනු ඇතැයි මට විශ්වාස නැතත් - මුහුණු වර්ග රාශියක් සහ විය හැකි මුහුණු අගයන් රාශියක් සමඟ සෙවීම

— රොබ් බේලි

7

මෙය පැරණි පිළිතුරකි, නමුත් මට තවමත් සාකච්ඡාවට ටිකක් දායක විය හැකිය. REST, RESTful සහ ගෘහ නිර්මාණ ශිල්පය පිළිබඳ වැරදි වැටහීමක් මම බොහෝ විට නිරීක්ෂණය කර ඇත්තෙමි. RESTful කිසි විටෙකත් සෙවුම් ගොඩනැඟීම ගැන කිසිවක් සඳහන් නොකරයි, ගෘහ නිර්මාණ ශිල්පය පිළිබඳ RESTful හි කිසිවක් නැත, එය සැලසුම් මූලධර්ම හෝ නිර්ණායක සමූහයකි.

සෙවීමක් වඩා හොඳ ආකාරයකින් විස්තර කිරීම සඳහා අපට විශේෂයෙන් ගෘහ නිර්මාණ ශිල්පයක් ගැන කතා කළ යුතු අතර වඩා හොඳින් ගැලපෙන්නේ සම්පත් නැඹුරු ගෘහ නිර්මාණ ශිල්පය (ROA) ය.

RESTful හි සැලසුම් කිරීම සඳහා මූලධර්ම තිබේ, idempotent යන්නෙන් අදහස් කරන්නේ මා සමහර පිළිතුරු කියවන විට ප්‍රති result ලය වෙනස් කළ නොහැකි බවයි, එයින් අදහස් කරන්නේ ස්වාධීන ඉල්ලීමක ප්‍රති result ලය කොපමණ වාරයක් ක්‍රියාත්මක වේද යන්න මත රඳා නොපවතින බවයි. එය වෙනස් විය හැකිය, RESTful Api විසින් සපයනු ලබන සමහර දත්ත සමඟ එය පෝෂණය කරන දත්ත සමුදායක් මම නිරන්තරයෙන් යාවත්කාලීන කරමි, එම GET ක්‍රියාත්මක කිරීමෙන් ප්‍රති result ලය වෙනස් විය හැකි නමුත් එය කොපමණ වාරයක් ක්‍රියාත්මක කර ඇත්ද යන්න මත රඳා නොපවතී. මට ලෝකය කැටි කිරීමට හැකි නම්, එයින් අදහස් වන්නේ වෙනත් ප්‍රති .ලයකට තුඩු දෙන සම්පතක් ඉල්ලා සිටින විට සේවයේ කිසිදු රාජ්‍යයක්, පරිවර්තනයක් හෝ සේවාවක් නොමැති බවයි.

නිර්වචනය අනුව, සම්පතක් යනු තමා විසින්ම දෙයක් ලෙස සඳහන් කිරීම වැදගත් වන ඕනෑම දෙයකි.

සම්පත් නැඹුරු ගෘහ නිර්මාණ ශිල්පය තුළ (දැන් සිට එය ROA ලෙස හඳුන්වමු) අපි බොහෝ දේ විය හැකි සම්පත කෙරෙහි අවධානය යොමු කරමු:

ලේඛනයක අනුවාදයකි
ලේඛනයේ අවසන් යාවත්කාලීන කළ අනුවාදය
සෙවුමකින් ලැබෙන ප්‍රති result ලයක්
වස්තු ලැයිස්තුවක්
මම ඊ-වාණිජ්‍යයකින් මිලදී ගත් පළමු ලිපිය

සම්පත අනුව එය අද්විතීය වන්නේ ලිපින හැකියාව නිසා එහි ඇත්තේ එක් යූආර්අයි එකක් පමණි

ROA සලකා බැලීමේදී සෙවීම RESTful හි හොඳින් ගැලපේ . ඔබගේ සෙවීම සාමාන්‍ය සෙවුමක් බවත් එය කිසිවක් වෙනස් නොකරන බවත් මා සිතන හෙයින් අපට GET භාවිතා කළ යුතුය. එබැවින් එය අනර්ථකාරී ය (එකතු කරන ලද නව මූලද්‍රව්‍ය මත පදනම්ව එය විවිධ දේ ආපසු ලබා දුන්නද). ROA වෙත නොව RESTful වෙත ඇලී සිටිය හැකි නිසා මෙහි ව්‍යාකූලතාවයක් ඇත, එයින් අදහස් කරන්නේ මට ROA හි ලිපින හැකියාව පිළිබඳ මූලධර්මය භාවිතා නොකරන නිසා සෙවීමක් නිර්මාණය කර විවිධ දේ එකම පරාමිතීන් සමඟ ආපසු ලබා දිය හැකි රටාවක් අනුගමනය කළ හැකි බවයි. කොහොමද ඒක? හොඳයි, ඔබ ශරීරයේ සෙවුම් පෙරහන් යවන්නේ නම් හෝ ශීර්ෂකය සම්පත ADDRESSABLE නොවේ.

W3 මුල් ලේඛනයේ ඔබට හරියටම කුමක්ද සහ URI හි මූලධර්ම සොයාගත හැකිය:

https://www.w3.org/DesignIssues/Axioms

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

RESTful හි ROA රටාව අනුගමනය කිරීමෙන් සෙවීම වෙනත් සම්පතකට වඩා වැඩි නොවේ, එකම වෙනස වන්නේ සම්පත් වස්තුවට relation ජු සම්බන්ධතාවයක් වෙනුවට ගණනය කිරීමකින් ලැබෙන සම්පත් ය. පහත දැක්වෙන රටාව මත පදනම්ව සරල ගණිතමය ගණනය කිරීමේ සේවාවක් මට ආමන්ත්‍රණය කර ලබා ගත හැකි මූලධර්මය මත පදනම්ව:

http://myapi.com/sum/1/2

එහිදී එකතුව, 1 සහ 2 වෙනස් කළ හැකි නමුත් ගණනය කිරීමේ ප්‍රති result ලය අද්විතීය වන අතර එය ඇඩ්‍රස් කළ හැකි ය, මම එකම පරාමිතීන් සමඟ අමතන සෑම අවස්ථාවකම මම ලබා ගන්නේ එකම හා සේවයේ කිසිදු වෙනසක් නොවේ. Resouce / sum / 1/2 සහ / substract / 5/4 මූලධර්මවලට හොඳින් ඇලී සිටී.

— මැක්සිමිලියානෝ රියෝස්
source

5

සලකා බැලිය යුතු එක් ප්‍රවේශයක් නම්, හැකි විමසුම් සමූහයක් එකතු කිරීමේ සම්පතක් ලෙස සැලකීමයි, උදා /jobs/filters.

POSTශරීරයේ විමසුම් පරාමිතීන් සමඟ මෙම සම්පත සඳහා වන ඉල්ලීම් මඟින් නව සම්පතක් නිර්මාණය කිරීම හෝ පවතින සමාන පෙරණයක් හඳුනාගෙන එහි හැඳුනුම්පත අඩංගු URL යක් ආපසු ලබා දෙනු ඇත : /jobs/filters/12345.

රැකියා සඳහා GET ඉල්ලීමකදී හැඳුනුම්පත භාවිතා කළ හැකිය : /jobs?filter=12345. GETපෙරහන් සම්පත පිළිබඳ පසුකාලීන ඉල්ලීම් මඟින් පෙරනයේ අර්ථ දැක්වීම නැවත ලබා දෙනු ඇත.

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

මෙම ප්‍රවේශයේ ඇති අඩුපාඩුවක් නම් ඔබට URL හි කියවීමේ හැකියාව නැති වීමයි ( GETපෙරහන් සම්පත සඳහා ඉල්ලීමක් වුවද අර්ථ දැක්වීම ලබා ගැනීමෙන් මෙය අවම කර ගත හැකි වුවද ). මෙම හේතුව නිසා ඔබට /jobsපෙරහන් සම්පතක් සඳහා සහාය වන පරිදි සම්පතේ ඇති විමසුම් පරාමිතීන්ගේ සමාන හෝ අනු කාණ්ඩයකට සහය දැක්වීමට ඔබට අවශ්‍ය විය හැකිය . කෙටි විමසුම් සඳහා මෙය භාවිතා කළ හැකිය. මෙම අංගය සපයා තිබේ නම්, පෙරහන් වර්ග දෙක අතර හැඹිලි හැකියාව පවත්වා ගැනීම සඳහා, /jobsසම්පත පිළිබඳ විමසුම් පරාමිතීන් භාවිතා කරන විට , ක්‍රියාත්මක කිරීම මඟින් අභ්‍යන්තරව පෙරහන් සම්පතක් නිර්මාණය කිරීම / නැවත භාවිතා කිරීම සහ URL ස්වරූපයෙන් දැක්වෙන තත්වයක් 302හෝ 303තත්වයක් ආපසු ලබා දිය යුතුය /jobs?filter=12345.

— pgraham
source

මේ සඳහා මගේ පළමු ප්‍රතිචාරය නම් එය හොඳ තොරතුරු වන අතර එය සැබවින්ම බර්නිං ග්‍රාමා විසින් සපයන ලද පිළිතුරෙහි විචලනයකි. අත්යවශ්යයෙන්ම එය "පෙරණය / සෙවීම නමින් නව වස්තුවක් සාදන්න, එය නිර්මාණය කිරීමට අමතන්න, පසුව එය ලබා ගැනීමට අමතන්න". විචලනය වන්නේ එය නැවත ලබා ගැනීම සඳහා වන ඇමතුම එය එකතුවකට යෙදීම සඳහා වූ ඇමතුමකට සමානය. සිත්ගන්නා සුළුය. කෙසේ වෙතත් ඔබගේ සහ දැවෙන ග්‍රැම්මාගේ පිළිතුර එකම ගැටලුවකින් පීඩා විඳිති - මට පෙරහන් නිර්මාණය කිරීමට කිසිදු කැමැත්තක් නැත. ඒවායින් විශාල ප්‍රමාණයක් ඇති අතර, ඒවා නැවත ක්‍රියාත්මක කිරීම සඳහා හැර ඒවා ගබඩා කිරීම අවශ්‍ය නොවේ.

— රොබ් බේලි

2

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

— pgraham

ඔබට පෙරහන් ගබඩා කිරීමේ අවශ්‍යතාවය මඟහරවා ගත හැකිය ... ඒවා ගබඩා නොකිරීම. REST පිළිබඳ කිසිවක් එය නොනැසී පවතින බවට සහතික නොවේ. ඔබට ඉල්ලීමක් කළ හැකි අතර ප්‍රති GET /jobs/37result ලයක් ලැබෙනු ඇත, එවිට යමෙකු සම්පත මකා දමා තත්පර 2 කට පසුව එම ඉල්ලීම 404 ක් ලබා දෙයි. ඒ හා සමානව ඔබ POST /searchesසහ ඔබ සෙවුම් ප්‍රති result ලයකට හරවා යවනු ලැබේ නම් (සෙවීම නිර්මාණය කර ඔබට 201 ක් ලැබෙනු ඇත තත්පර 2 කට පසුව එම ප්‍රති result ලය මතකයෙන් අතුගා දැමිය හැකි අතර නැවත උත්පාදනය කළ යුතුය. දිගු කාලීන ගබඩා කිරීම අවශ්ය නොවේ.

— stevendesu

3

එක් යූආර්අයි සඳහා සෑම විටම එකම ප්‍රති results ල (නිරූපණය) ලබා දෙන ස්ථිතික එකතුවක් තිබේ නම් GET හරි. මෙම නිරූපණයන් ජනනය කරන දත්ත කිසි විටෙකත් වෙනස් නොවන බව ද එයින් ගම්‍ය වේ. මූලාශ්‍රය කියවීමට පමණි දත්ත ගබඩාවකි.

එක ම URI සඳහා ලබා ගන්න ආපසු වෙනස් ප්රතිඵල සහිත උල්ලංඝනය idempotency / ආරක්ෂාව සහ CoolURI මූලධර්මය හා ඒ නිසාම ය ඔයාගෙද නොවේ . අනන්‍යතා ක්‍රියාපද දත්ත සමුදායකට ලිවීමට හැකි නමුත් ඒවා කිසි විටෙකත් නිරූපණයට බලපාන්නේ නැත.

පොදු සෙවුමක් ආරම්භ වන්නේ POST ඉල්ලීමකින් වන අතර එය ප්‍රති .ලයට යොමු කිරීමක් ලබා දෙයි. එය ප්‍රති result ලය ජනනය කරයි (එය අළුත් වන අතර පසුව GET සමඟ ලබා ගත හැකිය). මෙම ප්‍රති result ලය ධූරාවලි විය හැකිය (ඔබට ලබා ගත හැකි යූආර්අයි සමඟ වැඩිදුර යොමු කිරීම්), ඇත්ත වශයෙන්ම, යෙදුමට අර්ථවත් නම්, පෙර සෙවුම්වල අංග නැවත භාවිතා කළ හැකිය.

මාර්ගය වන විට, මම දන්නවා මිනිසුන් එය වෙනස් ආකාරයකින් කරන බව. REST උල්ලං to නය කිරීම කොතරම් පහසුදැයි ඔබ මට පැහැදිලි කිරීමට අවශ්‍ය නැත.

— මාටින් සුගියෝටෝ
source

Aaaaaaah - ඉතින් ඒක තමයි වැඩ කරන්න ඕනේ! ස්තූතියි!

— රොබ් බේලි

4

Idempotency යන්නෙන් අදහස් කරන්නේ එය සැමවිටම එකම ලෙස ආපසු යා යුතු බව නොවේ, කිසිවක් වෙනස් නොවන්නේ නම් එය නැවත ලබා දිය යුතුය. සෙවීම ගණනය කිරීමේ ප්‍රති result ලයක් ලෙස සැලකිය හැකි අතර එය සම්පතකි.

— මැක්සිමිලියානෝ රියෝස්

Idempotency ඇත්ත වශයෙන්ම කරන්නේ ප්‍රති the ලය එලෙසම පවතින බවයි. හැඹිලි පාලනය භාවිතා කිරීම ඔබට කළ හැකි අතර එය ප්‍රායෝගික වේ. පසුකාලීන GET වලට බාධා කරන DELETE භාවිතා කිරීමට ඔබට හැකිය. කෙසේ වෙතත්, යෙදුමේ අභ්‍යන්තර ක්‍රියාකාරකම් පිළිබඳ දැනුමක් තබා ගැනීමට නියෝජිතයෙකුට අවශ්‍ය නම්, එය තවදුරටත් RESTful නොවේ. ඉහත, මම කතා කළේ REST පිළිබඳ අතිශය ආන්තික අදහස ගැන ය. ප්රායෝගිකව, මිනිසුන්ට එහි බොහෝ අංශ උල්ලං can නය කළ හැකිය. හැඹිලි තවදුරටත් කාර්යක්ෂමව හැඹිලි නොකරන විට ඔවුන් මිල ගෙවයි.

— මාටින් සුගියෝටෝ

1

"අයිඩම්පොටෙන්සි ඇත්ත වශයෙන්ම අදහස් කරන්නේ ප්‍රති result ලය එලෙසම පවතින බවයි." ... ඉල්ලීමෙන් පසුව. කාරණය නම්, එම ඉල්ලීම දත්ත වෙනස් නොකරන බවයි.

— ඇන්ඩ්‍රිමොටින්ගා