HTTP / 1.1 පිරිවිතරයට අනුව:

POSTවිසින් හඳුනාගෙන ඇති සම්පතේ නව යටත් නිලධාරියෙකු ලෙස ඉල්ලීමෙහි ඇතුළත් කර ඇති ආයතනය සම්භවය සේවාදායකයා විසින් පිළිගන්නා ලෙස ඉල්ලා සිටීමට මෙම ක්‍රමය භාවිතා කරයි Request-URI.Request-Line

වෙනත් වචන වලින් කිවහොත්, නිර්මාණය කිරීමටPOST භාවිතා වේ .

මෙම PUTආවරිත අස්තිත්වයක් වන කර්මයක් යටතේ ගබඩා කළ බව ක්රමය ඉල්ලීම් Request-URI. Request-URIදැනටමත් පවතින සම්පතක් ගැන සඳහන් කරන්නේ නම් , සංවෘත වස්තුව ආරම්භක සේවාදායකයේ වාසය කරන නවීකරණය කරන ලද අනුවාදයක් ලෙස සැලකිය යුතුය. Request-URIපවත්නා සම්පතක් වෙත යොමු නොවන්නේ නම් සහ ඉල්ලුම් කරන පරිශීලක නියෝජිතයා විසින් යූආර්අයි නව සම්පතක් ලෙස අර්ථ දැක්විය හැකි නම්, ආරම්භක සේවාදායකයාට එම යූආර්අයි සමඟ සම්පත් නිර්මාණය කළ හැකිය.

එනම්, නිර්මාණය කිරීමට හෝ ප්‍රතිස්ථාපනය කිරීමටPUT භාවිතා කරයි .

ඉතින්, සම්පතක් නිර්මාණය කිරීම සඳහා භාවිතා කළ යුත්තේ කුමක්ද? නැතහොත් යමෙකුට මේ දෙකටම සහාය දිය යුතුද?

සමස්ත:

නිර්මාණය සඳහා PUT සහ POST යන දෙකම භාවිතා කළ හැකිය.

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

විශිෂ් both දෙකම භාවිතා කළ හැකිය, එබැවින් මගේ RESTful නිර්මාණයේදී මා භාවිතා කළ යුත්තේ කුමක්ද:

ඔබට PUT සහ POST යන දෙකටම සහාය වීමට අවශ්‍ය නැත.

භාවිතා කරන දේ ඔබට ඉතිරිව ඇත. නමුත් ඉල්ලීමෙහි ඔබ සඳහන් කරන්නේ කුමන වස්තුව මත පදනම්ව නිවැරදි එකක් භාවිතා කිරීමට මතක තබා ගන්න.

සලකා බැලිය යුතු කරුණු:

• ඔබ පැහැදිලිවම නිර්මාණය කරන URL වස්තු ඔබ නම් කරනවාද, නැතහොත් සේවාදායකයාට තීරණය කිරීමට ඉඩ දෙනවාද? ඔබ ඒවා නම් කරන්නේ නම් PUT භාවිතා කරන්න. ඔබ සේවාදායකයාට තීරණය කිරීමට ඉඩ දෙන්නේ නම් POST භාවිතා කරන්න.
• PUT idempotent වේ, එබැවින් ඔබ වස්තුවක් දෙවරක් තැබුවහොත් එයට කිසිදු බලපෑමක් නැත. මෙය කදිම දේපලක් බැවින් හැකි සෑම විටම මම PUT භාවිතා කරමි.
• ඔබට එකම වස්තු URL සමඟ PUT සමඟ සම්පතක් යාවත්කාලීන කිරීමට හෝ නිර්මාණය කිරීමට හැකිය
• POST සමඟ ඔබට එකවර ඉල්ලීම් 2 ක් URL වෙත වෙනස් කිරීම් කළ හැකි අතර ඒවා වස්තුවේ විවිධ කොටස් යාවත්කාලීන කළ හැකිය.

උදාහරණයක්:

මේ සම්බන්ධයෙන් SO පිළිබඳ තවත් පිළිතුරක කොටසක් ලෙස මම පහත සඳහන් දේ ලිව්වෙමි .

තැපැල්:

සම්පතක් වෙනස් කිරීමට සහ යාවත්කාලීන කිරීමට භාවිතා කරයි

POST /questions/<existing_question> HTTP/1.1
Host: www.example.com/

පහත සඳහන් දෝෂයක් බව සලකන්න:

POST /questions/<new_question> HTTP/1.1
Host: www.example.com/

URL තවමත් නිර්මාණය කර නොමැති නම්, නම සඳහන් කිරීමේදී එය නිර්මාණය කිරීම සඳහා ඔබ POST භාවිතා නොකළ යුතුය. මෙය <new_question>තවමත් නොපවතින බැවින් 'සම්පත් සොයාගත නොහැකි' දෝෂයක් ඇති විය යුතුය. ඔබ <new_question> පළමුව සේවාදායකයේ ඇති සම්පත් දැමිය යුතුය .

POST භාවිතයෙන් සම්පත් නිර්මාණය කිරීම සඳහා ඔබට මෙවැනි දෙයක් කළ හැකිය:

POST /questions HTTP/1.1
Host: www.example.com/

මෙම අවස්ථාවේදී සම්පත් නාමය සඳහන් කර නොමැති නම්, නව වස්තු URL මාර්ගය ඔබ වෙත ආපසු ලබා දෙන බව සලකන්න.

පුට්:

සම්පතක් නිර්මාණය කිරීමට හෝ එය නැවත ලිවීමට භාවිතා කරයි. ඔබ සම්පත් නව URL නියම කරන අතරතුර.

නව සම්පතක් සඳහා:

PUT /questions/<new_question> HTTP/1.1
Host: www.example.com/

පවතින සම්පතක් නැවත ලිවීමට:

PUT /questions/<existing_question> HTTP/1.1
Host: www.example.com/

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

4.3.4. පුට්

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

ඔබට කියන දේ වෙබයේ සොයාගත හැකිය

• සම්පතක් නිර්මාණය කිරීම සඳහා POST භාවිතා කළ යුතු අතර, එකක් වෙනස් කිරීමට PUT භාවිතා කළ යුතුය
• සම්පතක් නිර්මාණය කිරීම සඳහා PUT භාවිතා කළ යුතු අතර, POST එකක් වෙනස් කිරීමට භාවිතා කළ යුතුය

දෙකම හරි නැත.

අනන්‍යතාවය මත පදනම්ව PUT සහ POST අතර තෝරා ගැනීම වඩා හොඳයක්‍රියාවෙහි .

PUT යන්නෙන් අදහස් කරන්නේ සම්පතක් තැබීමයි - ලබා දී ඇති URL හි ඇති ඕනෑම දෙයක් වෙනත් දෙයක් සමඟ සම්පූර්ණයෙන්ම ප්‍රතිස්ථාපනය කිරීම. නිර්වචනය අනුව, PUT යනු අනර්ථකාරී ය. ඔබ කැමති වාර ගණනක් එය කරන්න, ප්‍රති result ලය සමාන වේ. x=5මෝඩයි. සම්පතක් කලින් තිබේද නැද්ද යන්න ඔබට පුට් කළ හැකිය (උදා: නිර්මාණය කිරීමට හෝ යාවත්කාලීන කිරීමට)!

POST සම්පතක් යාවත්කාලීන කරයි, අනුබද්ධ සම්පතක් එක් කරයි, හෝ වෙනසක් ඇති කරයි. පෝස්ට් එකක් අනභිභවනීය නොවන අයුරින් x++වෙනස් නොවේ.

මෙම තර්කය අනුව, PUT යනු ඔබ නිර්මාණය කරන දෙයෙහි URL ඔබ දැනගත් විට නිර්මාණය කිරීමයි. ඔබට නිර්මාණය කිරීමට අවශ්‍ය දේවල් කාණ්ඩය සඳහා "කර්මාන්තශාලාවේ" හෝ කළමනාකරුගේ URL ඔබ දන්නා විට නිර්මාණය කිරීමට POST භාවිතා කළ හැකිය.

ඒ නිසා:

POST /expense-report

හෝ:

PUT  /expense-report/10929

• තැපැල් URL එකක් ළමා සම්පත් නිර්මාණය දෙස සේවාදායකය අර්ථ URL එක.
• URL එකකට PUT ග්‍රාහක අර්ථ දක්වා ඇති URL එකෙහි සම්පත සම්පුර්ණයෙන්ම නිර්මාණය කරයි / ප්‍රතිස්ථාපනය කරයි .
• URL එකකට පැච් කිරීම එම සේවාදායකයා විසින් නිර්වචනය කරන ලද URL හි සම්පතේ කොටසක් යාවත්කාලීන කරයි.

PUT සහ POST සඳහා අදාළ පිරිවිතර RFC 2616 .59.5ff වේ.

POST ළමා සම්පතක් නිර්මාණය කරයි , එබැවින් POST /itemsසම්පත යටතේ ජීවත්වන සම්පත් නිර්මාණය කිරීමට /items. උදා. /items/1. එකම පෝස්ට් පැකට්ටුව දෙවරක් යැවීමෙන් සම්පත් දෙකක් නිර්මාණය වේ.

PUT යනු සේවාදායකයා දන්නා URL එකක සම්පතක් නිර්මාණය කිරීම හෝ ප්‍රතිස්ථාපනය කිරීම ය .

එබැවින්: PUT යනු CREATE සඳහා අපේක්ෂකයෙකු පමණි, එහිදී සම්පත් නිර්මාණය කිරීමට පෙර සේවාදායකයා url එක දැන සිටියි. උදා. /blogs/nigel/entry/when_to_use_post_vs_putමාතෘකාව සම්පත් යතුර ලෙස භාවිතා කරන බැවින්

PUT දැනටමත් පවතින URL එකෙහි සම්පත් තිබේ නම් එය ප්‍රතිස්ථාපනය කරයි, එබැවින් එකම ඉල්ලීම දෙවරක් යැවීමෙන් කිසිදු බලපෑමක් නැත. වෙනත් වචන වලින් කිවහොත්, PUT වෙත කෙරෙන ඇමතුම් අනර් are ය .

RFC මෙසේ කියවයි:

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

සටහන: PUT බොහෝ දුරට සම්පත් යාවත්කාලීන කිරීම සඳහා භාවිතා කර ඇත (ඒවා සම්පුර්ණයෙන්ම ප්‍රතිස්ථාපනය කිරීමෙන්), නමුත් මෑතකදී PATCH භාවිතා කරමින් පවතින සම්පත් යාවත්කාලීන කිරීම සඳහා යොමුවී ඇත, PUT විසින් මුළු සම්පත ප්‍රතිස්ථාපනය කරන බව නියම කරයි. RFC 5789.

යාවත්කාලීන 2018 : PUT වළක්වා ගැනීම සඳහා කළ හැකි නඩුවක් තිබේ. "PUT නොමැතිව REST" බලන්න

“PUT නොමැතිව REST” තාක්‍ෂණය සමඟින් අදහස වන්නේ නව 'නාමකරණය කළ' ඉල්ලීම් සම්පත් පළ කිරීමට පාරිභෝගිකයින්ට බල කිරීමයි. කලින් සාකච්ඡා කළ පරිදි, ගනුදෙනුකරුගේ තැපැල් ලිපිනය වෙනස් කිරීම නව “ChangeOfAddress” සම්පතකට තැපැල් කිරීමකි, වෙනස් තැපැල් ලිපින ක්ෂේත්‍ර වටිනාකමක් ඇති “පාරිභෝගික” සම්පතක PUT නොවේ.

REST API Design වෙතින් ලබාගෙන ඇත - සම්පත් ආකෘති නිර්මාණය සිතුවිලි වල ප්‍රකාශ් සුබ්‍රමනියම් විසිනි

එක් සම්පතක් යාවත්කාලීන කිරීම සඳහා බහු සේවාදායකයින් සමඟ ඇති රාජ්‍ය සංක්‍රාන්ති ගැටලු වළක්වා ගැනීමට මෙය API ට බල කරන අතර සිදුවීම් මූලාශ්‍ර හා CQRS සමඟ වඩාත් හොඳින් ගැලපේ. කාර්යය අසමමුහුර්තව සිදු කළ විට, පරිවර්තනය පෝස්ට් කිරීම සහ එය ක්‍රියාත්මක වන තෙක් බලා සිටීම සුදුසු යැයි පෙනේ.

සාරාංශය:

සාදන්න:

PUT හෝ POST යන දෙකින්ම පහත පරිදි සිදු කළ හැකිය:

පුට්

නිර්මාණය ද සමග නව සම්පතක් newResourceId තිබෙන / සම්පත් URI, හෝ යටතේ, හඳුනාගැනීමේ ලෙස එකතු .

PUT /resources/<newResourceId> HTTP/1.1 

තැපැල්

නිර්මාණය කරන ලද / සම්පත් URI යටතේ නව සම්පත්, හෝ එකතු . සාමාන්‍යයෙන් හඳුනාගැනුම සේවාදායකයා විසින් ආපසු ලබා දෙනු ලැබේ.

POST /resources HTTP/1.1

යාවත්කාලීන කිරීම:

හැකි එකම පහත සඳහන් ආකාරයට දමන්න සමග සිදු කළ:

පුට්

/ සම්පත් URI, හෝ එකතු කිරීම යටතේ, පවතින සම්පත් සම්පත් සමඟ අනන්‍යතාවය ලෙස සම්පත් යාවත්කාලීන කරයි .

PUT /resources/<existingResourceId> HTTP/1.1

පැහැදිලි කිරීම:

පොදු ලෙස බෝපාල් සහ URI සමඟ කටයුතු කරන විට, ඔබ Generic බලපත්රය යටතේ අවසර ලබා ඇත මත වම් සහ විශේෂිත මත අයිතිය . මෙම generics සාමාන්යයෙන් හැඳින්වේ එකතු සහ වඩාත් නිශ්චිත භාණ්ඩ ලෙස හැඳින්විය හැක සම්පත් . සම්පතක් තුළ එකතුවක් අඩංගු විය හැකි බව සලකන්න .

උදාහරණ:

<- සාමාන්‍ය - විශේෂිත ->

URI: website.com/users/john
website.com  - whole site
users        - collection of users
john         - item of the collection, or a resource

URI:website.com/users/john/posts/23
website.com  - whole site
users        - collection of users
john         - item of the collection, or a resource
posts        - collection of posts from john
23           - post from john with identifier 23, also a resource

ඔබ පළ භාවිතා කරන විට ඔබ කරන්නේ සෑම විටම එය අනවසරකරුවන්ගේ එකතුව , ඒ නිසා සෑම විටම ඔබ කියනවා

POST /users HTTP/1.1

ඔබ පරිශීලක එකතුවට නව පරිශීලකයෙකු පළ කරයි .

ඔබ ඉදිරියට ගොස් මේ වගේ දෙයක් උත්සාහ කරන්නේ නම්:

POST /users/john HTTP/1.1

එය ක්‍රියාත්මක වනු ඇත, නමුත් අර්ථාන්විතව ඔබ කියන්නේ පරිශීලක එකතුව යටතේ ජෝන් එකතුවට සම්පතක් එක් කිරීමට අවශ්‍ය බවය .

ඔබ PUT භාවිතා කළ පසු ඔබ යොමු කරන්නේ සම්පතක් හෝ තනි අයිතමයක්, සමහරවිට එකතුවක් තුළ විය හැකිය . එබැවින් ඔබ කියන විට:

PUT /users/john HTTP/1.1

ඔබ කියන්නේ සේවාදායක යාවත්කාලයට හෝ එය නොපවතී නම් නිර්මාණය කරන්න, පරිශීලක එකතුව යටතේ ඇති ජෝන් සම්පත .

පිරිවිතර:

පිරිවිතරයේ වැදගත් කොටස් කිහිපයක් ඉස්මතු කිරීමට මට ඉඩ දෙන්න:

තැපැල්

මෙම තනතුර ක්රමය සම්භවය සේවාදායකය එම ඉල්ලීම කිරීම සඳහා භාවිතා වේ පිළිගැනීමට ඉල්ලීම තුළ ලෙස මේ සමඟ අමුණා ඇති ස්ංකීර්ණ නව යටත් ඉල්ලීම්-Line දී ඉල්ලීම්-URI මගින් හඳුනාගත් සම්පත්

එබැවින්, එකතුවක් මත නව සම්පතක් නිර්මාණය කරයි .

පුට්

මෙම දාන්න ආවරිත ආයතනයක් කරන ක්රමය ඉල්ලීම් ගබඩා සැපයුම් ඉල්ලීම්-URI යටතේ. ඉල්ලීම-යූආර්අයි දැනටමත් පවතින සම්පතක් ගැන සඳහන් කරන්නේ නම් , සංවෘත ආයතනය මූලාරම්භක සේවාදායකයේ වාසය කරන නවීකරණය කරන ලද අනුවාදයක් ලෙස සැලකිය යුතුය . ඉල්ලීම්-URI කරන්නේ නම් , දැනට පවතින මේ මොහොතේ නැති සම්පත්, සහ URI බව හැකි ලෙස අර්ථ ඇති නව සම්පත් කොතෙකුත් ඉල්ලා පරිශීලක නියෝජිතයා විසින් සම්භවය සේවාදායකය හැකි නිර්මාණය බව URI සමග සම්පත්. "

එබැවින් සම්පතේ පැවැත්ම මත පදනම්ව නිර්මාණය කිරීම හෝ යාවත්කාලීන කිරීම .

යොමුව:

• HTTP / 1.1 පිරිවිතර
• විකිපීඩියා - REST
• ඒකාකාර සම්පත් හඳුනාගැනීම් (යූආර්අයි): සාමාන්‍ය සින්ටැක්ස් සහ අර්ථ නිරූපණය

POST "පරිශීලකයෙකු නිර්මාණය කිරීම සඳහා ආදානය මෙන්න, මා වෙනුවෙන් එය සාදන්න" යන්නෙහි අර්ථය "නව නිර්මාණය කරන්න" යන්නයි.

PUT "ඇතුලත් කරන්න, දැනටමත් තිබේ නම් ප්‍රතිස්ථාපනය කරන්න" යන්නෙහි තේරුම "පරිශීලක 5 සඳහා දත්ත මෙන්න" යන්නයි.

ඔබ තවමත් පරිශීලකයා POSTනොදන්නා බැවින් example.com/users වෙත යන්න URL, ඔබට අවශ්‍ය වන්නේ සේවාදායකය එය නිර්මාණය කිරීමයි.

ඔබට නිශ්චිත පරිශීලකයෙකු PUTප්‍රතිස්ථාපනය කිරීමට / නිර්මාණය කිරීමට අවශ්‍ය බැවින් ඔබ example.com/users/id වෙත යන්න .

එකම දත්ත සමඟ දෙවරක් පෝස්ට් කිරීම යනු විවිධ අයිඩී සහිත සමාන පරිශීලකයින් දෙදෙනෙකු නිර්මාණය කිරීමයි. එකම දත්ත සමඟ දෙවරක් PUT කිරීමෙන් පළමු වරට පරිශීලකයා නිර්මාණය වන අතර දෙවන වරටත් ඔහු එම තත්වයටම යාවත්කාලීන වේ (වෙනස්කම් නොමැත). ඔබ PUTඑය කොපමණ වාර ගණනක් සිදු කළත් එකම තත්වයෙන් අවසන් වන හෙයින්, එය සෑම අවස්ථාවකදීම “සමානව බලසම්පන්න” යැයි කියනු ලැබේ. ඉල්ලීම් ස්වයංක්‍රීයව නැවත උත්සාහ කිරීම සඳහා මෙය ප්‍රයෝජනවත් වේ. ඔබ බ්‍රව්සරයේ පිටුපස බොත්තම එබූ විට 'නැවත යැවීමට ඔබට අවශ්‍ය යැයි ඔබට විශ්වාසද' නැත.

සාමාන්‍ය උපදෙසක් නම් ඔබේ සම්පත් උත්පාදනය POSTපාලනය කිරීමට සේවාදායකයාට අවශ්‍ය වූ විට භාවිතා URLකිරීමයි. PUTවෙනත් ආකාරයකින් භාවිතා කරන්න . PUT වඩා කැමති POST.

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

එබැවින්: පවතින පරිශීලකයෙකු සුරැකීමට, හෝ සේවාදායකයා විසින් හැඳුනුම්පත ජනනය කරන අතර හැඳුනුම්පත අද්විතීය බව තහවුරු කර ඇත:

PUT /user/12345 HTTP/1.1  <-- create the user providing the id 12345
Host: mydomain.com

GET /user/12345 HTTP/1.1  <-- return that user
Host: mydomain.com

එසේ නොමැතිනම්, මුලින් වස්තුව නිර්මාණය කිරීමට POST භාවිතා කරන්න, සහ වස්තුව යාවත්කාලීන කිරීමට PUT භාවිතා කරන්න:

POST /user HTTP/1.1   <--- create the user, server returns 12345
Host: mydomain.com

PUT /user/12345 HTTP/1.1  <--- update the user
Host: mydomain.com

නිර්මාණය කිරීමට POST සහ යාවත්කාලීන කිරීමට PUT භාවිතා කරන්න. කෙසේ වෙතත් රූබි ඔන් රේල්ස් එය කරන්නේ එයයි.

PUT    /items/1      #=> update
POST   /items        #=> create

සේවාදායකයා අතර සේවාදායකයා අතර දත්ත සම්ප්‍රේෂණය සඳහා දෙකම භාවිතා වේ, නමුත් ඒවා අතර සියුම් වෙනස්කම් ඇත, ඒවා නම්:

ප්‍රතිසම:

• දාන්න ගත සහ IE දමා එය වූයේ නැත.
• තැපැල් කාර්යාලයට තැපැල් යැවීම ලෙස තැපැල් කරන්න .

සමාජ මාධ්‍ය / ජාල ප්‍රතිසම:

• තැපැල් සමාජ මාධ්ය මත: අපි පෝස්ට් විට, එය නව පශ්චාත් නිර්මාණය කරයි.
• අප දැනටමත් පළ කර ඇති පණිවිඩය සඳහා (එනම් සංස්කරණය කරන්න) තබන්න .

REST යනු ඉතා ඉහළ මට්ටමේ සංකල්පයකි. ඇත්ත වශයෙන්ම, එය HTTP ගැනවත් සඳහන් නොකරයි!

HTTP හි REST ක්‍රියාත්මක කරන්නේ කෙසේද යන්න පිළිබඳව ඔබට යම් සැකයක් ඇත්නම්, ඔබට සැමවිටම පරමාණු ප්‍රකාශන ප්‍රොටොකෝලය (AtomPub) පිරිවිතර දෙස බැලිය හැකිය . AtomPub යනු HTTP සමඟ RESTful වෙබ් සේවා ලිවීම සඳහා වන ප්‍රමිතියක් වන අතර එය බොහෝ HTTP සහ REST ලුමිනියර්ස් විසින් වැඩි දියුණු කරන ලදී.

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

සම්පත් නිර්මාණය කිරීම ගැන AtomPub ට කියන්නට ඇත්තේ මෙයයි (9.2 කොටස):

එකතුවකට සාමාජිකයින් එකතු කිරීම සඳහා, සේවාදායකයින් එකතු කිරීමේ URI වෙත POST ඉල්ලීම් යවයි.

HTTP + REST API සහිත සේවාදායකයක සම්පතක් නිර්මාණය කිරීම සඳහා PUT හෝ POST භාවිතා කළ යුතුද යන්න තීරණය වන්නේ URL ව්‍යුහය අයිති කාටද යන්න මතය. සේවාදායකයා දැන සිටීම හෝ නිර්වචනය කිරීමට සහභාගී වීම, URL ව්‍යුහය යනු SOA වෙතින් ඇති වූ අනවශ්‍ය කප්ලිං වලට සමාන අනවශ්‍ය සම්බන්ධ කිරීමකි. REST එතරම් ජනප්‍රිය වීමට හේතුව කප්ලිං වර්ග වලින් ගැලවීමයි. එබැවින් භාවිතා කිරීමට සුදුසු ක්‍රමය POST වේ. මෙම රීතියට ව්‍යතිරේකයන් ඇති අතර ඒවා සිදුවන්නේ සේවාදායකයා විසින් එය යොදවා ඇති සම්පත් වල ස්ථාන ව්‍යුහය පාලනය කිරීමට කැමති විටය. මෙය දුර්ලභ වන අතර වෙනත් දෙයක් වැරදියි.

මෙම අවස්ථාවේදී සමහර අය එසේ නම් තර්ක කරනු ඇත RESTful-URL භාවිතා , සේවාදායකයා සම්පතේ URL දන්නා බවත් එබැවින් PUT පිළිගත හැකි බවත්ය. සියල්ලට පසු, කැනොනිකල්, සාමාන්‍යකරණය කළ, රූබි ඔන් රේල්ස්, ජැන්ගෝ යූආර්එල් වැදගත් වන්නේ මේ නිසා ය, ට්විටර් ඒපීඅයි දෙස බලන්න… බ්ලහ් බ්ලා බ්ලා. විවේක-යූආර්එල් වැනි දෙයක් නොමැති බවත්, රෝයි ෆීල්ඩින් විසින්ම මෙසේ ප්‍රකාශ කරන බවත් එම ජනතාව තේරුම් ගත යුතුය .

REST API මඟින් ස්ථාවර සම්පත් නම් හෝ ධූරාවලිය නිර්වචනය නොකළ යුතුය (පැහැදිලිවම සේවාදායකයා සහ සේවාදායකයා සම්බන්ධ කිරීම). සේවාදායකයින්ට තමන්ගේ නාම අවකාශය පාලනය කිරීමට නිදහස තිබිය යුතුය. ඒ වෙනුවට, HTML ආකෘති සහ යූආර්අයි සැකිලි වැනි සුදුසු යූආර්අයි සාදා ගන්නේ කෙසේද යන්න පිළිබඳව සේවාදායකයින්ට උපදෙස් දීමට සේවාදායකයන්ට ඉඩ දෙන්න. [මෙහි අසමත් වීමෙන් ගම්‍ය වන්නේ සේවාදායකයින් සම්පත් ව්‍යුහයක් උපකල්පනය කරන්නේ ඩොමේන්-විශේෂිත ප්‍රමිතියක් වැනි කලාපීය තොරතුරු නිසා වන අතර එය දත්ත මත පදනම් වූ ආර්පීසී ක්‍රියාකාරී සම්බන්ධතාවයට සමාන වේ].

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

අ RESTful-URL ඇත්ත වශයෙන්ම REST උල්ලං is නය කිරීමක් වන බැවින් සේවාදායකයා URL ව්‍යුහය භාරව සිටින අතර එය සම්බන්ධ වීම වළක්වා ගැනීම සඳහා එය භාවිතා කරන්නේ කෙසේද යන්න තීරණය කිරීමට නිදහස තිබිය යුතුය. මෙය ව්‍යාකූල වුවහොත් API නිර්මාණය පිළිබඳ ස්වයං සොයාගැනීමේ වැදගත්කම ගැන කියවන්න.

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

1. සේවාදායකයා සේවාදායකයට නව සම්පතක් පළ කරයි.
2. සේවාදායකයා ඉල්ලීම ක්‍රියාවට නංවා ප්‍රතිචාරයක් යවයි.
3. සේවාදායකයාට කිසි විටෙකත් ප්‍රතිචාර නොලැබේ.
4. සේවාදායකයාට ප්‍රතිචාරය ලැබී නොමැති බව සේවාදායකයා නොදනී.
5. සේවාදායකයාට සම්පත සඳහා URL එකක් නොමැත (එබැවින් PUT විකල්පයක් නොවේ) සහ POST නැවත කරයි.
6. POST අව්‍යාජ නොවන අතර සේවාදායකයා…

6 වන පියවර යනු කුමක් කළ යුතුද යන්න පිළිබඳව මිනිසුන් සාමාන්‍යයෙන් ව්‍යාකූල වීමයි. කෙසේ වෙතත්, මෙම ගැටළුව විසඳීම සඳහා ක්ලඩ්ජ් නිර්මාණය කිරීමට හේතුවක් නැත. ඒ වෙනුවට, RFC 2616 හි නිශ්චිතව දක්වා ඇති පරිදි HTTP භාවිතා කළ හැකි අතර සේවාදායකයා පිළිතුරු දෙයි:

10.4.10 409 ගැටුම

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

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

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

ගැටුම් 409 හි තත්ව කේතයක් සමඟ පිළිතුරු සැපයීම නිවැරදි මඟකි :

• දැනටමත් පද්ධතියේ ඇති සම්පතකට ගැලපෙන හැඳුනුම්පතක් ඇති දත්ත POST සිදු කිරීම “සම්පතෙහි වත්මන් තත්වය සමඟ ගැටුමකි.”
• වැදගත් කොටස සේවාදායකයාට සම්පත් ඇති බව වටහා ගැනීම සහ සුදුසු ක්‍රියාමාර්ග ගැනීම ය. මෙය “තත්වය (ය) වන අතර ගැටුම නිරාකරණය කර ඉල්ලීම නැවත ඉදිරිපත් කිරීමට පරිශීලකයාට හැකි වනු ඇතැයි අපේක්ෂා කෙරේ.”
• RFC 2616 අනුව පරමාදර්ශී අවස්ථාව වන “ගැටුමේ හැඳුනුම්පත සහ සම්පත සඳහා සුදුසු පූර්ව කොන්දේසි සහිත සම්පත් වල URL ය අඩංගු ප්‍රතිචාරයක්“ පරිශීලකයාට හෝ පරිශීලක නියෝජිතයාට ගැටලුව විසඳීමට ප්‍රමාණවත් තොරතුරු ”සපයයි.

2616 ප්‍රතිස්ථාපනය කිරීම සඳහා RFC 7231 නිකුත් කිරීම මත පදනම්ව යාවත්කාලීන කරන්න

RFC 7231 නිර්මාණය කර ඇත්තේ 2616 වෙනුවට ය. 4.3.3 වගන්තියේ POST සඳහා අනුගමනය කළ හැකි ප්‍රතිචාරය විස්තර කෙරේ

POST සැකසීමේ ප්‍රති result ලය පවත්නා සම්පතක් නිරූපණය කිරීමට සමාන වේ නම්, මූලාරම්භක සේවාදායකයක් විසින් පරිශීලක නියෝජිතයා එම සම්පත වෙත හරවා යවනු ලැබේ. පරිශීලක නියෝජිතයාට සම්පත් හැඳුනුම්පතක් ලබා දීමෙන් සහ හවුල් හැඹිලි සඳහා වඩාත් සුදුසු ක්‍රමයක් හරහා නිරූපණය මාරු කිරීමේ වාසි මෙහි ඇත, නමුත් අමතර ඉල්ලීමක වියදමින් පරිශීලක නියෝජිතයාට දැනටමත් නිරූපණය හැඹිලි නොමැති නම්.

POST නැවත නැවත සිදු වුවහොත් 303 ක් ආපසු ලබා දීමට එය දැන් පෙළඹවිය හැකිය. කෙසේ වෙතත්, ප්රතිවිරුද්ධය සත්යයකි. 303 නැවත ලබා දීම අර්ථවත් වනුයේ බහුවිධ නිර්මාණ ඉල්ලීම් (විවිධ සම්පත් නිර්මාණය කිරීම) එකම අන්තර්ගතය ලබා දෙන්නේ නම් පමණි. උදාහරණයක් ලෙස සේවාදායකයා සෑම විටම නැවත බාගත කිරීම අවශ්‍ය නොවන "ඔබගේ ඉල්ලීම් පණිවිඩය ඉදිරිපත් කිරීම ගැන ස්තූතියි". RFC 7231 තවමත් 4.2.2 වගන්තියේ POST නිරර්ථක නොවිය යුතු අතර POST නිර්මාණය සඳහා භාවිතා කළ යුතු බව දිගටම පවත්වාගෙන යයි.

මේ පිළිබඳ වැඩි විස්තර සඳහා මෙම ලිපිය කියවන්න .

RFC 2616 හි PUT අර්ථ දැක්වීමෙන් මම මෙම උපදෙස් වලට කැමතියි :

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

මෙහි ඇති අනෙක් උපදෙස් සමඟ මෙය විහිළුවට ලක් කරයි, දැනටමත් නමක් ඇති සම්පත් සඳහා PUT වඩාත් සුදුසු වන අතර, පවතින සම්පතක් යටතේ නව වස්තුවක් නිර්මාණය කිරීම සඳහා POST හොඳය (සහ සේවාදායකයාට එය නම් කිරීමට ඉඩ දෙයි).

මම මෙය අර්ථ නිරූපණය කරමි, සහ PUT හි අනන්‍යතා අවශ්‍යතා, එයින් අදහස් කරන්නේ:

• එකතුවක් යටතේ නව වස්තූන් නිර්මාණය කිරීම සඳහා POST හොඳයි (සහ නිර්මාණය කිරීම අනර්ථකාරී විය යුතු නැත)
• පවත්නා වස්තූන් යාවත්කාලීන කිරීම සඳහා PUT හොඳයි (සහ යාවත්කාලීන කිරීම ප්‍රබල විය යුතුය)
• පවත්නා වස්තූන් සඳහා අවිනිශ්චිත නොවන යාවත්කාලීන කිරීම් සඳහා ද POST භාවිතා කළ හැකිය (විශේෂයෙන්, වස්තුවක කොටසක් සියල්ලම සඳහන් නොකර වෙනස් කිරීම - ඔබ ඒ ගැන සිතන්නේ නම්, එකතුවක නව සාමාජිකයෙකු නිර්මාණය කිරීම ඇත්ත වශයෙන්ම මේ ආකාරයේ විශේෂ අවස්ථාවකි එකතු කරන්න, දෘෂ්ටි කෝණයෙන් යාවත්කාලීන කරන්න)
• PUT භාවිතා කිරීම සඳහා භාවිතා කළ හැක්කේ සම්පත නම් කිරීමට සේවාදායකයාට ඉඩ දෙන්නේ නම් පමණි. නමුත් REST සේවාදායකයින් URL ව්‍යුහය ගැන උපකල්පන නොකළ යුතු බැවින්, මෙය අපේක්ෂිත දේවල අඩුය.

කෙටියෙන්:

PUT idempotent වේ, එහිදී එකම මෙහෙයුම එක් වරක් හෝ කිහිප වතාවක් ක්‍රියාත්මක කළහොත් සම්පත් තත්වය සමාන වේ.

POST යනු අවිනිශ්චිත නොවන අතර, එක් වරක් ක්‍රියාත්මක කිරීමට සාපේක්ෂව මෙහෙයුම කිහිප වතාවක් ක්‍රියාත්මක කළහොත් සම්පත් තත්වය වෙනස් විය හැකිය.

දත්ත සමුදා විමසුම සමඟ ප්‍රතිසම

PUT ඔබට "UPDATE STUDENT SET address =" abc "ට සමාන යැයි සිතිය හැකිය, එහිදී id =" 123 ";

තැපැල් ඔබට "ශිෂ්‍යයාට ඇතුල් කරන්න (නම, ලිපිනය) වටිනාකම් (" abc "," xyzzz ") වැනි දෙයක් ගැන සිතිය හැකිය;

ශිෂ්‍ය හැඳුනුම්පත ස්වයංක්‍රීයව ජනනය වේ.

PUT සමඟ, එකම විමසුම කිහිප වතාවක් හෝ එක් වරක් ක්‍රියාත්මක කරන්නේ නම්, STUDENT වගු තත්වය එලෙසම පවතී.

POST සම්බන්ධයෙන් ගත් කල, එකම විමසුම කිහිප වතාවක් ක්‍රියාත්මක කළ හොත්, දත්ත සමුදාය තුළ ශිෂ්‍ය වාර්තා කිහිපයක් නිර්මාණය වන අතර, “INSERT” විමසුමක් ක්‍රියාත්මක කිරීමේදී දත්ත සමුදායේ තත්වය වෙනස් වේ.

සටහන: PUT සඳහා යාවත්කාලීනයක් සිදුවිය යුතු සම්පත් ස්ථානයක් (දැනටමත්-සම්පත්) අවශ්‍ය වන අතර POST ට එය අවශ්‍ය නොවේ. එබැවින් බුද්ධිමත්ව POST යනු නව සම්පතක් නිර්මාණය කිරීම සඳහා වන අතර දැනටමත් පවතින සම්පත් යාවත්කාලීන කිරීම සඳහා PUT අවශ්‍ය වේ.

POST සමඟ යාවත්කාලීන කිරීම් සිදු කළ හැකි යැයි සමහරු ඉදිරිපත් විය හැකිය. යාවත්කාල කිරීම් සඳහා කුමන එකක් භාවිතා කළ යුතුද යන්න හෝ නිර්මාණය කිරීම සඳහා භාවිතා කළ යුතු දැඩි රීතියක් නොමැත. නැවතත් මේවා සම්මුතීන් වන අතර, බුද්ධිමත්ව මම ඉහත සඳහන් තර්කණයට නැඹුරු වී එය අනුගමනය කරමි.

POST යනු තැපැල් පෙට්ටියකට ලිපියක් පළ කිරීම හෝ ඊමේල් පෝලිම්වලට තැපැල් කිරීම වැනි ය. PUT යනු ඔබ වස්තුවක් කුහර කුහරයක හෝ ස්ථානයක රාක්කයක තැබූ විටය (එයට දන්නා ලිපිනයක් ඇත).

POST සමඟ, ඔබ පළ කරන්නේ QUEUE හෝ COLLECTION ලිපිනයට ය. PUT සමඟ, ඔබ ITEM ලිපිනයට යොමු කරයි.

PUT අනර් is ය. ඔබට ඉල්ලීම 100 වතාවක් යැවිය හැකි අතර එය වැදගත් නොවේ. POST නිරර්ථක නොවේ. ඔබ ඉල්ලීම 100 වතාවක් යවන්නේ නම්, ඔබට තැපැල් පෙට්ටියේ ඊමේල් 100 ක් හෝ ලිපි 100 ක් ලැබෙනු ඇත.

සාමාන්‍ය රීතියක්: ඔබ අයිතමයේ හැඳුනුම්පත හෝ නම දන්නේ නම්, PUT භාවිතා කරන්න. ලැබීමේ පාර්ශවය විසින් අයිතමයේ හැඳුනුම්පත හෝ නම පැවරීමට ඔබට අවශ්‍ය නම්, POST භාවිතා කරන්න.

නව පිළිතුර (දැන් මම REST වඩා හොඳින් තේරුම් ගෙන ඇත):

PUT යනු හුදෙක් සේවාදායකයා විසින් හඳුනාගෙන ඇති සම්පත නිරූපණය කිරීම සඳහා සේවාව මෙතැන් සිට භාවිතා කළ යුතු අන්තර්ගතයේ ප්‍රකාශයකි; POST යනු සේවාවේ අන්තර්ගතය, මෙතැන් සිට අඩංගු විය යුතු (සමහරවිට අනුපිටපත් විය හැකි) ප්‍රකාශයකි, නමුත් එම අන්තර්ගතය හඳුනා ගන්නේ කෙසේද යන්න සේවාදායකයා සතුය.

PUT x( සම්පතක්x හඳුනා ගන්නේ නම් ): "හඳුනාගත් සම්පතේ අන්තර්ගතය මගේ අන්තර්ගතය සමඟ ප්‍රතිස්ථාපනය කරන්න ."x

PUT x( xසම්පතක් හඳුනා නොගන්නේ නම් ): "මගේ අන්තර්ගතය අඩංගු නව සම්පතක් සාදා xඑය හඳුනා ගැනීමට භාවිතා කරන්න."

POST x: "මගේ අන්තර්ගතය ගබඩා කර, එම අන්තර්ගතය අඩංගු සම්පතක් (පැරණි හෝ නව) හඳුනා ගැනීමට මට භාවිතා කළ හැකි හඳුනාගැනීමක් මට ලබා දෙන්න (සමහර විට වෙනත් අන්තර්ගතයන් සමඟ මිශ්‍ර විය හැක). සම්පත xහඳුනාගත හැකි දේට සමාන හෝ යටත් විය යුතුය ." " y හි සම්පත x හි සම්පතට යටත් වේ " යන්න සාමාන්‍යයෙන් ක්‍රියාත්මක වන්නේ y හි x (උදා: x = /fooසහ y = /foo/bar) හි උප මාර්ගයක් බවට පත් කිරීමෙන් සහ x පැවැත්ම පිළිබිඹු හි සම්පත් නව සම්පතක්, උදා: අධි-සබැඳියක් සමඟ y හි සම්පත් සහ සමහර පාර- දත්තවල නිරූපණයන් වෙනස් කිරීමෙනි . REST හි URLs පාරදෘශ්‍ය බැවින් හොඳ සැලසුමකට සැබවින්ම අත්‍යවශ්‍ය වන්නේ දෙවැන්න පමණි - ඔබ හයිපර්මීඩියා භාවිතා කළ යුතුය සේවාව හරහා ගමන් කිරීම සඳහා සේවාදායකයාගේ පාර්ශවීය URL ඉදිකිරීම වෙනුවට.

REST හි, "අන්තර්ගතය" අඩංගු සම්පතක් වැනි දෙයක් නොමැත. නිරූපණය නිරතුරුවම ඉදිරිපත් කිරීම සඳහා සේවාව භාවිතා කරන දත්ත වලට මම "අන්තර්ගතය" ලෙස හඳුන්වමි. එය සාමාන්‍යයෙන් දත්ත සමුදායක හෝ ගොනුවක අදාළ පේළි කිහිපයකින් සමන්විත වේ (උදා: රූප ගොනුවක්). පරිශීලකයාගේ අන්තර්ගතය සේවාවට භාවිතා කළ හැකි දෙයක් බවට පරිවර්තනය කිරීම සේවාව සතු ය, උදා: JSON ගෙවීමක් SQL ප්‍රකාශ බවට පරිවර්තනය කිරීම.

මුල් පිළිතුර (කියවීමට පහසු විය හැකිය) :

PUT /something( /somethingදැනටමත් තිබේ නම් ): "ඔබ සතුව ඇති ඕනෑම දෙයක් රැගෙන /somethingමා ඔබට දෙන දේ වෙනුවට ආදේශ කරන්න."

PUT /something( /somethingදැනටමත් නොපවතී නම්): "මම ඔබට දෙන දේ රැගෙන එය තබන්න /something."

POST /something: "මම ඔබට ලබා දෙන දෙය රැගෙන ඔබ අවසන් /somethingවූ පසු එහි URL මට ලබා දෙන තාක් කල් ඔබට අවශ්‍ය ඕනෑම තැනක තබන්න ."

කෙටි පිළිතුර:

සරල නියමය: නිර්මාණය කිරීමට POST භාවිතා කරන්න, යාවත්කාලීන කිරීමට PUT භාවිතා කරන්න.

දිගු පිළිතුර:

තැපැල්:

• සේවාදායකයට දත්ත යැවීමට POST භාවිතා කරයි.
• සම්පතේ URL නොදන්නා විට ප්‍රයෝජනවත් වේ

පුට්:

• PUT භාවිතා කරනුයේ තත්වය සේවාදායකයට මාරු කිරීමට ය
• සම්පතක URL එක දන්නා විට ප්‍රයෝජනවත් වේ

දිගු පිළිතුර:

එය වටහා ගැනීම සඳහා අප ප්‍රශ්න කළ යුත්තේ PUT අවශ්‍ය වූයේ ඇයි, POS විසින් විසඳීමට උත්සාහ කළ ගැටලු මොනවාද?

REST ගෘහ නිර්මාණ ශිල්පයේ දෘෂ්ටි කෝණයෙන් බලන විට කිසිවක් වැදගත් නොවේ. අපට PUT නොමැතිව ජීවත් වීමට ඉඩ තිබුණි. නමුත් සේවාදායක සංවර්ධකයෙකුගේ දෘෂ්ටි කෝණයෙන් එය ඔහුගේ / ඇයගේ ජීවිතය බෙහෙවින් සරල කළේය.

PUT ට පෙර, සේවාදායකයාට ජනනය කරන ලද URL ය හෝ එය ජනනය කළ සියල්ලම හෝ සේවාදායකයට යැවිය යුතු දත්ත දැනටමත් යාවත්කාලීන වී තිබේද නැද්ද යන්න සේවාදායකයින්ට කෙලින්ම දැනගත නොහැක. PUT මෙම සියලු හිසරදයන්හි සංවර්ධකයාට සහනයක් ලබා දුන්නේය. PUT අනර්ථකාරී ය, PUT ධාවන තත්වයන් හසුරුවයි, සහ PUT සේවාදායකයාට URL තෝරා ගැනීමට ඉඩ දෙයි.

රූබි ඔන් රේල්ස් 4.0 අර්ධ යාවත්කාලීන කිරීම් සඳහා PUT වෙනුවට 'PATCH' ක්‍රමය භාවිතා කරයි.

පැච් ගැන RFC 5789 පවසයි (1995 සිට):

අන්තර් ක්‍රියාකාරිත්වය වැඩි දියුණු කිරීමට සහ දෝෂ වළක්වා ගැනීමට නව ක්‍රමයක් අවශ්‍ය වේ. සම්පූර්ණ නව ශරීරයක් සහිත සම්පතක් නැවත ලිවීමට PUT ක්‍රමය දැනටමත් අර්ථ දක්වා ඇති අතර අර්ධ වෙනස්කම් කිරීමට නැවත භාවිතා කළ නොහැක. එසේ නොමැති නම්, ප්‍රොක්සි සහ හැඹිලි, සහ සේවාදායකයින් සහ සේවාදායකයන් පවා මෙහෙයුමේ ප්‍රති result ලය ලෙස ව්‍යාකූල විය හැකිය. POST දැනටමත් භාවිතා කර ඇති නමුත් පුළුල් අන්තර් ක්‍රියාකාරීත්වයක් නොමැතිව (එකක් සඳහා, පැච් ආකෘති සහාය සොයා ගැනීමට සම්මත ක්‍රමයක් නොමැත). PATCH කලින් HTTP පිරිවිතරයන්හි සඳහන් කර ඇති නමුත් එය සම්පූර්ණයෙන්ම අර්ථ දක්වා නැත.

" එජ් රේල්ස්: පැච් යනු යාවත්කාලීන කිරීම් සඳහා වන නව ප්‍රාථමික HTTP ක්‍රමයයි " එය පැහැදිලි කරයි.

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

නිවැරදි දේ කිරීමට සේවාදායකයාට පූර්ණ විශ්වාසයක් තැබිය නොහැකි වූ විට, නව අයිතමයක් නිර්මාණය කිරීම සඳහා POST භාවිතා කිරීම වඩාත් සුදුසු වන අතර ප්‍රතිචාරයේ දී URL ය නැවත සේවාදායකයා වෙත යවන්න.

ඉතා සරල ආකාරයකින් මම ෆේස්බුක් කාලරාමුවෙහි උදාහරණය ගන්නෙමි.

1 වන අවස්ථාව: ඔබ ඔබේ කාලරාමුවෙහි යමක් පළ කරන විට, එය නව ප්‍රවේශයකි. එබැවින් මෙම අවස්ථාවේ දී ඔවුන් POST ක්‍රමය භාවිතා කරන්නේ POST ක්‍රමය අනන්‍ය නොවන නිසාය.

2 වන අවස්ථාව: ඔබේ මිතුරා පළමු වරට ඔබගේ සටහන ගැන අදහස් දක්වන්නේ නම්, එය ද දත්ත සමුදායේ නව ප්‍රවේශයක් නිර්මාණය කරනු ඇත, එබැවින් POST ක්‍රමය භාවිතා කරයි.

3 වන අවස්ථාව: ඔබේ මිතුරා ඔහුගේ අදහස සංස්කරණය කරන්නේ නම්, මේ අවස්ථාවේ දී ඔවුන්ට විවරණ හැඳුනුම්පතක් තිබුනි, එබැවින් ඔවුන් දත්ත සමුදායේ නව ප්‍රවේශයක් නිර්මාණය කරනවා වෙනුවට පවතින අදහසක් යාවත්කාලීන කරනු ඇත. එබැවින් මෙම වර්ගයේ ක්‍රියාකාරිත්වය සඳහා PUT ක්‍රමය භාවිතා කරන්න.

තනි පේළියක, දත්ත සමුදායට නව ප්‍රවේශයක් එක් කිරීමට POST සහ දත්ත සමුදායේ යමක් යාවත්කාලීන කිරීමට PUT භාවිතා කරන්න.

වැදගත්ම කරුණ වන්නේ විශ්වසනීයත්වයයි . POST පණිවිඩයක් නැති වුවහොත් පද්ධතියේ තත්වය නිර්වචනය නොකෙරේ. ස්වයංක්‍රීයව ප්‍රතිසාධනය කළ නොහැක. PUT පණිවිඩ සඳහා, රාජ්‍යය නිර්වචනය කර ඇත්තේ පළමු සාර්ථක නැවත උත්සාහ කරන තුරු පමණි.

උදාහරණයක් ලෙස, POST සමඟ ක්‍රෙඩිට් කාඩ් ගනුදෙනු නිර්මාණය කිරීම හොඳ අදහසක් නොවනු ඇත.

ඔබේ සම්පතෙහි ස්වයංක්‍රීයව ජනනය කරන ලද යූආර්අයි තිබේ නම්, ඔබට ජනනය කරන ලද යූආර්අයි (හිස් සම්පතක් වෙත යොමු කරමින්) සේවාදායකයාට ලබා දීමෙන් ඔබට තවමත් PUT භාවිතා කළ හැකිය.

තවත් කරුණු කිහිපයක්:

• POST මගින් අඩංගු වන සම්පතෙහි හැඹිලි පිටපත් අවලංගු කරයි (වඩා හොඳ අනුකූලතාවක්)
• POST ප්‍රතිචාර දැක්විය හැකි අතර POST ප්‍රතිචාර දැක්විය නොහැක (අන්තර්ගත-ස්ථානය සහ කල් ඉකුත්වීම අවශ්‍ය වේ)
• PUT සඳහා අඩු සහය දක්වන්නේ උදා: ජාවා ME, පැරණි බ්‍රව්සර්, ෆයර්වෝල්

මෙම මාතෘකාවට අළුත් පා ers කයන්ට ඔබ කළ යුතු දේ පිළිබඳ නිමක් නැති සාකච්ඡාව සහ අත්දැකීම් වලින් පාඩම් සාපේක්ෂ වශයෙන් නොපැවතීම යන කරුණු වලට පහර දෙනු ඇත . SOAP ට වඩා REST "වඩාත් කැමති" කාරණය නම්, මම සිතන්නේ අත්දැකීම් වලින් ඉහළ මට්ටමේ ඉගෙනීමක්, නමුත් යහපත්කම අප එතැන් සිට ඉදිරියට යා යුතුද? එය 2016. රෝයිගේ නිබන්ධනය 2000 දී විය. අප වර්ධනය කර ඇත්තේ කුමක්ද? එය විනෝදජනකද? සමඟ ඒකාබද්ධ වීම පහසු වූවාද? සහාය දීමට? එය ස්මාර්ට් ෆෝන් සහ දුර්වල ජංගම සම්බන්ධතා ඉහළ නැංවීමට කටයුතු කරයිද?

මට අනුව, සැබෑ ජීවිත ජාල විශ්වාස කළ නොහැකි ය. කල් ඉකුත් වීම ඉල්ලයි. සම්බන්ධතා යළි පිහිටුවනු ලැබේ. ජාලයන් වරකට පැය හෝ දින ගණනක් බැස යයි. දුම්රිය උමං තුලට යන්නේ ජංගම දුරකථන භාවිතා කරන්නන් සමඟ ය. ඕනෑම ඉල්ලීමක් සඳහා (ඉඳහිට මෙම සාකච්ඡාවේදී පිළිගත් පරිදි) ඉල්ලීම එහි යන විට ජලයට වැටිය හැකිය, නැතහොත් ප්‍රතිචාරය ආපසු එන විට ජලයේ වැටිය හැකිය. මෙම තත්වයන් තුළ, සාර්‍ථක සම්පත් වලට එරෙහිව සෘජුවම PUT, POST සහ DELETE ඉල්ලීම් නිකුත් කිරීම මට සෑම විටම ම්ලේච්ඡ හා අකාරුණික ලෙස බලපා ඇත.

ඉල්ලීම්-ප්‍රතිචාරය විශ්වාසදායක ලෙස සම්පූර්ණ කිරීම සහතික කිරීම සඳහා HTTP කිසිවක් නොකරයි, එය හරියටම ජාල දැනුවත් යෙදුම්වල කාර්යය වන නිසා එය හොඳයි. එවැනි යෙදුමක් සංවර්ධනය කිරීමෙන්, ඔබට POST වෙනුවට PUT භාවිතා කිරීමට කේන්දර හරහා පැනිය හැකිය, පසුව අනුපිටපත් ඉල්ලීම් ඔබ හඳුනා ගන්නේ නම් සේවාදායකයේ යම් ආකාරයක දෝෂයක් ලබා දීමට තවත් වළලු. සේවාදායකයා වෙත ආපසු ගොස්, මෙම දෝෂයන් අර්ථ නිරූපණය කිරීම, නැවත සකස් කිරීම, නැවත වලංගු කිරීම සහ නැවත තැපැල් කිරීම සඳහා ඔබට කේන්දර හරහා පැනිය යුතුය.

නැතහොත් ඔබට මෙය කළ හැකිය : ඔබගේ අනාරක්ෂිත ඉල්ලීම් ආධ්‍යාත්මික තනි පරිශීලක සම්පත් ලෙස සලකන්න (අපි ඒවා ක්‍රියාවන් ලෙස හඳුන්වමු). ගනුදෙනුකරුවන් සම්පතට හිස් පෝස්ට් එකක් සහිත සාර්‍ථක සම්පතක් සඳහා නව "ක්‍රියාවක්" ඉල්ලා සිටී. POST භාවිතා කරනුයේ මේ සඳහා පමණි. නැවුම් ලෙස සකස් කරන ලද ක්‍රියාවෙහි URI සුරක්ෂිතව සන්තකයේ තබා ගත් පසු, සේවාදායකයා ඉලක්කගත සම්පත නොව ක්‍රියාව URI වෙත අනාරක්ෂිත ඉල්ලීමක් ඉදිරිපත් කරයි . ක්‍රියාව නිරාකරණය කිරීම සහ “සැබෑ” සම්පත යාවත්කාලීන කිරීම ඔබේ API හි කාර්යය වන අතර එය විශ්වාස කළ නොහැකි ජාලයෙන් වෙන් කර ඇත.

සේවාදායකයා ව්‍යාපාරය කරයි, ප්‍රතිචාරය ලබා දෙන අතර එකඟ වූ ක්‍රියාදාම URI ට එරෙහිව එය ගබඩා කරයි . කිසියම් දෙයක් වැරදුනහොත්, සේවාදායකයා ඉල්ලීම පුනරාවර්තනය කරයි (ස්වාභාවික හැසිරීම!), සහ සේවාදායකයා දැනටමත් එය දැක තිබේ නම්, එය ගබඩා කළ ප්‍රතිචාරය පුනරාවර්තනය කරන අතර වෙන කිසිවක් නොකරයි .

පොරොන්දු සමඟ ඇති සමානකම ඔබ ඉක්මනින් හඳුනාගනු ඇත: කිසිවක් කිරීමට පෙර අපි ප්‍රති place ලය සඳහා ස්ථාන දරන්නා නිර්මාණය කර ආපසු එවන්නෙමු. පොරොන්දුවක් මෙන්, ක්‍රියාවක් එක් වරක් සාර්ථක හෝ අසාර්ථක විය හැකි නමුත් එහි ප්‍රති result ලය නැවත නැවත ලබා ගත හැකිය.

වඩාත්ම වැදගත් දෙය නම්, සුවිශේෂී ලෙස හඳුනාගෙන ඇති ක්‍රියාව ඔවුන්ගේ පරිසරය තුළ ඇති සුවිශේෂත්වය හා සම්බන්ධ කිරීමට අයදුම්පත් යැවීම සහ ලැබීම ය. සේවාදායකයින්ගෙන් වගකිවයුතු හැසිරීමක් ඉල්ලා සිටීමට සහ බලාත්මක කිරීමට අපට පටන් ගත හැකිය: ඔබගේ ඉල්ලීම් ඔබ කැමති තරම් නැවත නැවත කරන්න, නමුත් පවතින එකෙන් නිශ්චිත ප්‍රති result ලයක් ඔබ සතුව ඇති තුරු නව ක්‍රියාවක් ඇති නොකරන්න.

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

අනුක්‍රමික මකාදැමීමේ ඉල්ලීම්වලට 404 දෝෂයක් නොමැතිව මුල් තහවුරු කිරීම දැක බලා ගත හැකිය. දේවල් බලාපොරොත්තු වූවාට වඩා වැඩි කාලයක් ගත වුවහොත්, අපට තාවකාලිකව ප්‍රතිචාර දැක්විය හැකි අතර, නිශ්චිත ප්‍රති .ලය සඳහා සේවාදායකයාට නැවත පරීක්ෂා කළ හැකි ස්ථානයක් අපට තිබේ. මෙම රටාවේ ලස්සනම කොටස වන්නේ එහි කුං-ෆු (පැන්ඩා) දේපලයි. අපි දුර්වලකමක් ගනිමු, සේවාදායකයින්ට ප්‍රතිචාරය නොතේරෙන ඕනෑම වේලාවක ඉල්ලීමක් පුනරාවර්තනය කිරීමට ඇති හැකියාව සහ එය ශක්තියක් බවට පත් කිරීම :-)

මෙය RESTful නොවන බව මට පැවසීමට පෙර, REST මූලධර්මවලට ගරු කරන බොහෝ ක්‍රම සලකා බලන්න. සේවාදායකයින් URL සාදන්නේ නැත. අර්ථ නිරූපණයෙහි සුළු වෙනසක් තිබියදීත්, API සොයාගත හැකි මට්ටමක පවතී. HTTP ක්‍රියා පද සුදුසු පරිදි භාවිතා කරයි. මෙය ක්‍රියාත්මක කිරීම සඳහා විශාල වෙනසක් යැයි ඔබ සිතන්නේ නම්, එය එසේ නොවන බව මට අත්දැකීමෙන් ඔබට පැවසිය හැකිය.

ඔබට ගබඩා කිරීම සඳහා විශාල දත්ත ප්‍රමාණයක් ඇතැයි ඔබ සිතන්නේ නම්, අපි වෙළුම් කතා කරමු: සාමාන්‍ය යාවත්කාලීන තහවුරු කිරීමක් යනු කිලෝබයිට් භාගයකි. නිශ්චිතවම ප්‍රතිචාර දැක්වීමට HTTP දැනට ඔබට විනාඩියක් හෝ දෙකක් ලබා දෙයි. ඔබ ක්‍රියාවන් සතියක් පමණක් ගබඩා කළත්, ගනුදෙනුකරුවන්ට අල්ලා ගැනීමට ඕනෑ තරම් අවස්ථාවන් තිබේ. ඔබට ඉතා ඉහළ පරිමාවක් තිබේ නම්, ඔබට කැපවූ ඇසිඩ් අනුකූල යතුරු අගය ගබඩාවක් හෝ මතකයේ විසඳුමක් අවශ්‍ය විය හැකිය.

අනෙක් අය යෝජනා කරන වෙනස්කම් වලට අමතරව, මට තවත් එකක් එකතු කිරීමට අවශ්‍යයි.

දී තැපැල් ක්රමය ඔබ ශරීරය params යැවිය හැකform-data

දී Put ක්රමය ඔබ ශරීරය params යැවීමට ඇතිx-www-form-urlencoded

ශීර්ෂකය Content-Type:application/x-www-form-urlencoded

මේ අනුව, ඔබට PUT ක්‍රමයේදී ගොනු හෝ බහුපාර්ශ්වික දත්ත යැවිය නොහැක

සංස්කරණය කරන්න

"යෙදුම / x-www-form-urlencoded" යන අන්තර්ගත වර්ගය ASCII නොවන අක්ෂර අඩංගු ද්විමය දත්ත හෝ පෙළ විශාල ප්‍රමාණයක් යැවීමට අකාර්යක්ෂම වේ. ලිපිගොනු, ASCII නොවන දත්ත සහ ද්විමය දත්ත අඩංගු ආකෘති ඉදිරිපත් කිරීම සඳහා "බහුපාර්ට් / පෝරම-දත්ත" අන්තර්ගත වර්ගය භාවිතා කළ යුතුය.

එයින් අදහස් වන්නේ ඔබ ඉදිරිපත් කළ යුතු නම්

ගොනු, ASCII නොවන දත්ත සහ ද්විමය දත්ත

ඔබ POST ක්‍රමය භාවිතා කළ යුතුය

REST සේවා සඳහා HTTP PUT ක්‍රමයට එරෙහිව HTTP POST භාවිතා කරන්නේ කවදාද යන්න පිළිබඳව සෑම විටම යම් ව්‍යාකූලතාවයක් ඇති බව පෙනේ. බොහෝ සංවර්ධකයින් CRUD මෙහෙයුම් කෙලින්ම HTTP ක්‍රම සමඟ සම්බන්ධ කිරීමට උත්සාහ කරනු ඇත. මෙය නිවැරදි නොවන බවත්, CRUD සංකල්ප HTTP ක්‍රම සමඟ සම්බන්ධ කළ නොහැකි බවත් මම තර්ක කරමි. එනම්:

Create => HTTP PUT
Retrieve => HTTP GET
Update => HTTP POST
Delete => HTTP DELETE

CRUD මෙහෙයුම් වල R (etrieve) සහ D (elete) පිළිවෙලින් GET සහ DELETE යන HTTP ක්‍රම සමඟ සිතියම් ගත කළ හැකි බව සත්‍යයකි. කෙසේ වෙතත්, ව්යාකූලත්වය පවතින්නේ සී (රීට්) සහ යූ (යාවත්කාලීන) මෙහෙයුම් වල ය. සමහර අවස්ථා වලදී, යමෙකුට නිර්මාණය සඳහා PUT භාවිතා කළ හැකි අතර තවත් අවස්ථාවක POST අවශ්‍ය වේ. අපැහැදිලි භාවය පවතින්නේ HTTP PUT ක්‍රමයක් හා HTTP POST ක්‍රමයක් අතර අර්ථ දැක්වීම තුළ ය.

HTTP 1.1 පිරිවිතරයන්ට අනුව GET, HEAD, DELETE, සහ PUT ක්‍රම අනන්‍යතාවයෙන් යුක්ත විය යුතු අතර POST ක්‍රමය අනර්ථකාරී නොවේ. එනම්, මෙහෙයුමක් සම්පතක් මත එක් වරක් හෝ කිහිප වතාවක් සිදු කළ හැකි නම් සහ එම සම්පතේම එකම තත්වය නැවත ලබා දිය හැකි නම්, එය අනර්ථකාරී ය. අනේවාසික නොවන මෙහෙයුමකට එක් ඉල්ලීමක සිට තවත් ඉල්ලීමකට සම්පතේ නවීකරණය කරන ලද තත්වයක් ආපසු ලබා දිය හැකිය. එබැවින්, අවිනිශ්චිත නොවන මෙහෙයුමක දී, සම්පතකට සමාන තත්වයක් යමෙකුට ලැබෙනු ඇති බවට සහතිකයක් නොමැත.

ඉහත සඳහන් අයිඩම්පොටෙන්ට් අර්ථ දැක්වීම මත පදනම්ව, REST සේවා සඳහා HTTP POST ක්‍රමය භාවිතා කිරීමට එරෙහිව HTTP PUT ක්‍රමය භාවිතා කිරීම මගේ පියවරයි: විට HTTP PUT ක්‍රමය භාවිතා කරන්න:

The client includes all aspect of the resource including the unique identifier to uniquely identify the resource. Example: creating a new employee.
The client provides all the information for a resource to be able to modify that resource.This implies that the server side does not update any aspect of the resource (such as an update date).

අවස්ථා දෙකේදීම, මෙම මෙහෙයුම් එකම ප්‍රති .ල සමඟ කිහිප වතාවක් සිදු කළ හැකිය. එක් වරකට වඩා මෙහෙයුම ඉල්ලා සිටීමෙන් සම්පත් වෙනස් නොවේ. එබැවින් සැබෑ අවිනිශ්චිත මෙහෙයුමක්. පහත දැක්වෙන විට HTTP POST ක්‍රමය භාවිතා කරන්න:

The server will provide some information concerning the newly created resource. For example, take a logging system. A new entry in the log will most likely have a numbering scheme which is determined on the server side. Upon creating a new log entry, the new sequence number will be determined by the server and not by the client.
On a modification of a resource, the server will provide such information as a resource state or an update date. Again in this case not all information was provided by the client and the resource will be changing from one modification request to the next. Hence a non idempotent operation.

නිගමනය

REST සේවා සඳහා CRUD මෙහෙයුම් HTTP ක්‍රම සමඟ කෙලින්ම සහසම්බන්ධ නොකරන්න. HTTP POST ක්‍රමයට එදිරිව HTTP PUT ක්‍රමයක් භාවිතා කිරීම එම මෙහෙයුමේ අද්විතීය අංගය මත පදනම් විය යුතුය. එනම්, මෙහෙයුම අනර්ථකාරී නම්, HTTP PUT ක්‍රමය භාවිතා කරන්න. මෙහෙයුම අනර්ථකාරී නම්, HTTP POST ක්‍රමය භාවිතා කරන්න.

ප්‍රභව සේවාදායකයාට එම යූආර්අයි සමඟ සම්පත් නිර්මාණය කළ හැකිය

එබැවින් ඔබ POST භාවිතා කරන අතර බොහෝ විට සම්පත් නිර්මාණය සඳහා PUT අවශ්‍ය නොවේ. ඔබ දෙකටම සහාය දිය යුතු නැත. මට නම් POST පරිපූර්ණයි. එබැවින් එය නිර්මාණ තීරණයක්.

ඔබේ උපුටා දැක්වීම සඳහන් කළ පරිදි, IRI සඳහා කිසිදු සම්පතක් පවරා නොමැති අතර, කෙසේ හෝ සම්පතක් නිර්මාණය කිරීමට ඔබට අවශ්‍යය. උදාහරණයක් ලෙස, PUT /users/123/passwordසාමාන්‍යයෙන් පැරණි මුරපදය නව එකක් සමඟ ප්‍රතිස්ථාපනය කරයි, නමුත් එය දැනටමත් නොපවතී නම් මුරපදයක් සෑදීමට ඔබට එය භාවිතා කළ හැකිය (නිදසුනක් ලෙස, අලුතින් ලියාපදිංචි පරිශීලකයින් විසින් හෝ තහනම් පරිශීලකයින් ප්‍රතිස්ථාපනය කිරීමෙන්).

මම පහත සඳහන් දෑ සමඟ ගොඩබසිමි:

PUT යනු URI විසින් හඳුනාගත් සම්පතක්. මෙම අවස්ථාවේදී, ඔබ එය යාවත්කාලීන කරයි. එය සම්පත් ගැන සඳහන් කරන ක්‍රියා පද තුනේ කොටසකි - මකා දමා අනෙක් දෙක වීම.

POST යනු මූලික වශයෙන් නිදහස් පෝරම පණිවිඩයක් වන අතර එහි අර්ථය 'කලාපයෙන් පිටත' ලෙස අර්ථ දක්වා ඇත. පණිවිඩය නාමාවලියකට සම්පතක් එක් කිරීමක් ලෙස අර්ථ දැක්විය හැකි නම්, එය හරි ය, නමුත් මූලික වශයෙන් ඔබ සම්පත සමඟ කුමක් සිදුවේ දැයි දැන ගැනීමට ඔබ යවන පණිවිඩය (පළ කිරීම) තේරුම් ගත යුතුය.

PUT සහ GET සහ DELETE යනු සම්පතක් වෙත යොමු වන හෙයින් ඒවා අර්ථ දැක්වීම අනුවද නිර්‍මාණ වේ.

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

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

සංස්කරණය කරන්න: තවත් එක් දෙයක් - PUT හට නිර්මාණය කළ හැකි නමුත් එය එසේ වුවහොත් හැඳුනුම්පත ස්වාභාවික හැඳුනුම්පතක් විය යුතුය - AKA විද්‍යුත් තැපැල් ලිපිනයක්. ඔබ දෙවරක් PUT කරන විට, දෙවන කොටස පළමු යාවත්කාලීන කිරීමකි. මෙය අනර්ථකාරී ය .

හැඳුනුම්පත ජනනය කරන්නේ නම් (උදාහරණයක් ලෙස නව සේවක හැඳුනුම්පතක්), එකම URL එකක් සහිත දෙවන PUT මඟින් නව වාර්තාවක් නිර්මාණය කරනු ඇත, එය අනන්‍යතා රීතිය උල්ලං lates නය කරයි. මෙම අවස්ථාවේදී ක්‍රියා පදය POST වන අතර පණිවිඩය (සම්පත නොවේ) මෙම පණිවිඩයේ අර්ථ දක්වා ඇති අගයන් භාවිතා කරමින් සම්පතක් නිර්මාණය කිරීමයි.

අර්ථ නිරූපණය වෙනස් විය යුතුය, එම “PUT” තුළ, “GET” යනු පරමාදර්ශී විය යුතුය - අර්ථය, ඔබට එකම PUT ඉල්ලීම කිහිප වතාවක්ම කළ හැකි අතර ප්‍රති result ලය වනුයේ ඔබ එය එක් වරක් පමණක් ක්‍රියාත්මක කළ ආකාරයට ය.

වඩාත් පුළුල් ලෙස භාවිතා වන සහ වඩාත්ම ප්‍රයෝජනවත් යැයි සිතන සම්මුතීන් මම විස්තර කරමි:

ඔබ කිසියම් URL එකක සම්පතක් දැමූ විට සිදුවන්නේ එය එම URL එකෙන් සුරැකිය යුතුය, නැතහොත් එම රේඛා ඔස්සේ යමක්.

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

උදාහරණයක් ලෙස, ඔබට නව ප්‍රවාහයක් නිර්මාණය කිරීමට අවශ්‍ය වූ විට, ඔබට එය යම් URL එකකට දැමිය හැකිය. නමුත් ඔබට පවතින ධාරාවකට පණිවිඩයක් තැපැල් කිරීමට අවශ්‍ය වූ විට, ඔබ එහි URL වෙත තැපැල් කරන්න.

ධාරාවේ ගුණාංග වෙනස් කිරීම සඳහා, ඔබට එය PUT හෝ POST සමඟ කළ හැකිය. මූලික වශයෙන්, මෙහෙයුම අනර්ථකාරී වූ විට පමණක් "PUT" භාවිතා කරන්න - එසේ නොමැතිනම් POST භාවිතා කරන්න.

කෙසේ වෙතත්, GET හෝ POST හැර අනෙකුත් සියලුම නවීන බ්‍රව්සර් HTTP ක්‍රියාපද සඳහා සහය නොදක්වන බව සලකන්න.

බොහෝ විට, ඔබ ඒවා මේ ආකාරයෙන් භාවිතා කරනු ඇත:

• එකතුවකට සම්පතක් තැපැල් කරන්න
• එකතු කිරීම /: id මගින් හඳුනාගත් සම්පතක් තබන්න

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

• තැපැල් / අයිතම
• PUT / items / 1234

අවස්ථා දෙකේදීම, ඉල්ලීම් ශරීරය තුළ සම්පත් නිර්මාණය කිරීම හෝ යාවත්කාලීන කිරීම සඳහා දත්ත අඩංගු වේ. POST නිරවද්‍ය නොවන බව මාර්ග නාම වලින් පැහැදිලි විය යුතුය (ඔබ එය 3 වතාවක් අමතන්නේ නම් එය වස්තු 3 ක් නිර්මාණය කරයි), නමුත් PUT අනර්ථකාරී ය (ඔබ එය 3 වතාවක් අමතන්නේ නම් ප්‍රති result ලය සමාන වේ). PUT බොහෝ විට "උඩු යටිකුරු කිරීම" සඳහා භාවිතා කරයි (නිර්මාණය කිරීම හෝ යාවත්කාලීන කිරීම), නමුත් ඔබට එය වෙනස් කිරීමට භාවිතා කිරීමට අවශ්‍ය නම් ඔබට 404 දෝෂයක් නැවත ලබා දිය හැකිය.

POST විසින් එකතුවෙහි නව අංගයක් "නිර්මාණය" කරන අතර PUT දී ඇති URL එකක මූලද්‍රව්‍යයක් "ප්‍රතිස්ථාපනය කරයි", නමුත් අර්ධ වෙනස් කිරීම් සඳහා PUT භාවිතා කිරීම ඉතා සාමාන්‍ය සිරිතකි, එනම් පවතින සම්පත් යාවත්කාලීන කිරීමට පමණක් භාවිතා කරන්න සහ ශරීරයේ ඇතුළත් කළ ක්ෂේත්‍ර පමණක් වෙනස් කරන්න (අනෙක් ක්ෂේත්‍ර නොසලකා හැරීම). මෙය තාක්‍ෂණිකව වැරදියි, ඔබට REST-purist වීමට අවශ්‍ය නම්, PUT මුළු සම්පතම ප්‍රතිස්ථාපනය කළ යුතු අතර අර්ධ යාවත්කාලීන කිරීම සඳහා ඔබ PATCH භාවිතා කළ යුතුය. ඔබගේ සියලු API අන්ත ලක්ෂ්‍ය හරහා හැසිරීම පැහැදිලිව හා ස්ථාවරව පවතින තාක් දුරට මම පෞද්ගලිකව ගණන් ගන්නේ නැත.

මතක තබා ගන්න, REST යනු ඔබගේ API සරල ලෙස තබා ගැනීම සඳහා වූ සම්මුතීන් සහ මාර්ගෝපදේශ සමූහයකි. "RESTfull" කොටුව සලකුණු කිරීම සඳහා ඔබ සංකීර්ණ වැඩකටයුතු අවසන් කළහොත් ඔබ අරමුණ පරාජය කරයි;)

මේවා විස්තර කිරීමට අ nost ෙයවාදී ක්‍රමයක් තිබිය හැකි නමුත්, එය වෙබ් අඩවි වලට ලැබෙන පිළිතුරු වලින් විවිධ ප්‍රකාශ සමඟ ගැටෙන බවක් පෙනේ.

අපි මෙහි ඉතා පැහැදිලිව හා සෘජුව සිටිමු. ඔබ වෙබ් API සමඟ වැඩ කරන .NET සංවර්ධකයෙකු නම්, කරුණු (Microsoft API ප්‍රලේඛනයෙන්), http://www.asp.net/web-api/overview/creating-web-apis/creating-a-web -api-that-support-crud-operation :

1. PUT = UPDATE (/api/products/id)
2. MCSD Exams 2014 -  UPDATE = PUT, there are **NO** multiple answers for that question period.

යාවත්කාලීන කිරීම සඳහා ඔබට "POST" භාවිතා කළ හැකි බව සහතිකයි, නමුත් ඔබ ලබා දී ඇති රාමුව සමඟ ඔබ වෙනුවෙන් සකස් කර ඇති සම්මුතීන් අනුගමනය කරන්න. මගේ නඩුවේ එය .NET / Web API වේ, එබැවින් PUT යාවත්කාලීන කිරීම සඳහා විවාදයක් නොමැත.

ඇමසන් සහ සන් / ජාවා වෙබ් අඩවි සබැඳි සමඟ සියලු අදහස් කියවන ඕනෑම මයික්‍රොසොෆ්ට් සංවර්ධකයින්ට මෙය උපකාරී වනු ඇතැයි මම බලාපොරොත්තු වෙමි.

මෙන්න සරල රීතියක්:

පුට්එම URL හි ඇති සම්පත් යාවත්කාලීන කිරීමට හෝ නිර්මාණය කිරීමට URL එකකට භාවිතා කළ යුතුය.

වෙනත් ("යටත්") URL එකක පිහිටා ඇති හෝ HTTP හරහා සොයාගත නොහැකි සම්පතක් යාවත්කාලීන කිරීමට හෝ නිර්මාණය කිරීමට URL එකකට POST භාවිතා කළ යුතුය.

දත්ත සමුදා මෙහෙයුම් පිළිබඳව ඔබ හුරුපුරුදු නම්, තිබේ

1. තෝරන්න
2. ඇතුළු කරන්න
3. යාවත්කාලීන කරන්න
4. මකන්න
5. ඒකාබද්ධ කරන්න (යාවත්කාලීන කිරීම දැනටමත් තිබේ නම්, වෙනත් ඇතුළත් කරන්න)

මම PUTඒකාබද්ධ කිරීම සහ මෙහෙයුම් වැනි යාවත්කාලීන කිරීම් සහ POSTඇතුළත් කිරීම් සඳහා භාවිතා කරමි .

ප්රායෝගිකව, සම්පත් නිර්මාණය කිරීම සඳහා POST හොඳින් ක්රියා කරයි. අලුතින් සාදන ලද සම්පතේ URL ය ස්ථාන ප්‍රතිචාර ශීර්ෂය තුළ ආපසු ලබා දිය යුතුය. සම්පතක් සම්පූර්ණයෙන්ම යාවත්කාලීන කිරීම සඳහා PUT භාවිතා කළ යුතුය. RESTful API එකක් නිර්මාණය කිරීමේදී මේවා හොඳම භාවිතයන් බව කරුණාකර තේරුම් ගන්න. HTTP පිරිවිතරයන් සම්පත් නිර්මාණය කිරීම / යාවත්කාලීන කිරීම සඳහා සීමාවන් කිහිපයක් සමඟ PUT / POST භාවිතා කිරීම සීමා නොකරයි. හොඳම භාවිතයන් සාරාංශ කරන http://techoctave.com/c7/posts/71-twitter-rest-api-dissected දෙස බලන්න .