SOAP එදිරිව REST (වෙනස්කම්)

වෙබ් සේවා සන්නිවේදන ප්‍රොටෝකෝලයක් ලෙස SOAP සහ REST අතර ඇති වෙනස්කම් ගැන මම ලිපි කියවා ඇත්තෙමි, නමුත් SOAP ට වඩා REST සඳහා ඇති ලොකුම වාසි නම්:

1. REST වඩා ගතිකය, UDDI නිර්මාණය කිරීම සහ යාවත්කාලීන කිරීම අවශ්‍ය නොවේ (විශ්ව විස්තරය, සොයාගැනීම සහ ඒකාබද්ධ කිරීම).

2. REST XML ආකෘතියට පමණක් සීමා නොවේ. RESTful වෙබ් සේවාවන්ට සරල පෙළ / JSON / XML යැවිය හැකිය.

නමුත් SOAP වඩා ප්‍රමිතිගත වේ (උදා: ආරක්ෂාව).

ඉතින්, මෙම කරුණු වලදී මම නිවැරදිද?

අවාසනාවකට මෙන්, REST වටා වැරදි තොරතුරු සහ වැරදි වැටහීම් රාශියක් ඇත. ඔබේ ප්‍රශ්නය සහ @cmd හි පිළිතුර පමණක් නොව, ස්ටැක් පිටාර ගැලීම පිළිබඳ විෂයයට අදාළ බොහෝ ප්‍රශ්න සහ පිළිතුරු පිළිබිඹු කරයි.

SOAP සහ REST කෙලින්ම සැසඳිය නොහැක, මන්ද පළමුවැන්න ප්‍රොටෝකෝලයකි (හෝ අවම වශයෙන් වීමට උත්සාහ කරයි) සහ දෙවැන්න වාස්තු විද්‍යාත්මක ශෛලියකි. SOAP නොවන ඕනෑම HTTP API එකක් REST ලෙස හැඳින්වීමට මිනිසුන් පෙළඹෙන බැවින් මෙය අවට ඇති ව්‍යාකූලත්වයේ එක් ප්‍රභවයක් විය හැකිය.

දේවල් ටිකක් තල්ලු කර සංසන්දනයක් ඇති කිරීමට උත්සාහ කිරීම, SOAP සහ REST අතර ඇති ප්‍රධාන වෙනස වන්නේ සේවාදායකයා සහ සේවාදායක ක්‍රියාත්මක කිරීම් අතර සම්බන්ධ වීමේ ප්‍රමාණයයි. SOAP සේවාදායකයා අභිරුචි ඩෙස්ක්ටොප් යෙදුමක් මෙන් ක්‍රියා කරයි. සේවාදායකයා සහ සේවාදායකයා අතර දැඩි ගිවිසුමක් ඇති අතර, දෙපැත්තෙන්ම යමක් වෙනස් වුවහොත් සියල්ල බිඳී යනු ඇතැයි අපේක්ෂා කෙරේ. ඕනෑම වෙනස්වීමකින් පසු ඔබට නිරන්තර යාවත්කාලීන කිරීම් අවශ්‍ය වේ, නමුත් කොන්ත්රාත්තුව අනුගමනය කරන්නේ දැයි සොයා ගැනීම පහසුය.

REST සේවාදායකයෙක් බ්‍රව්සරයකට සමාන ය. එය ප්‍රොටෝකෝලයක් සහ ප්‍රමිතිගත ක්‍රම භාවිතා කරන්නේ කෙසේදැයි දන්නා සාමාන්‍ය සේවාදායකයෙක් වන අතර යෙදුමක් ඒ තුළට ගැලපේ. අමතර ක්‍රම නිර්මාණය කිරීමෙන් ඔබ ප්‍රොටෝකෝලය ප්‍රමිති උල්ලං do නය නොකරයි, ඔබ සම්මත ක්‍රමවේදයන් උත්තේජනය කර ඒවා සමඟ ඔබේ මාධ්‍ය වර්ගය මත ක්‍රියා නිර්මාණය කරයි. නිවැරදිව සිදු කළ හොත්, සම්බන්ධ කිරීම අඩු වන අතර වෙනස්කම් වඩාත් සුන්දර ලෙස විසඳා ගත හැකිය. ඇතුල් වීමේ ස්ථානය සහ මාධ්‍ය වර්ගය හැරුණු විට සේවාදායකයකු ඒපීඅයි පිළිබඳ ශුන්‍ය දැනුමක් ඇති REST සේවාවක් ඇතුළත් කළ යුතුය. SOAP හි, සේවාදායකයාට එය භාවිතා කරන සෑම දෙයක් ගැනම කලින් දැනුමක් අවශ්‍ය වේ, නැතහොත් එය අන්තර්ක්‍රියා ආරම්භ නොකරනු ඇත. මීට අමතරව, සේවාදායකයා විසින්ම සපයනු ලබන ඉල්ලුමට අනුව REST සේවාදායකයකු දීර් can කළ හැකිය,

REST යනු කුමක්ද සහ එය SOAP ට වඩා වෙනස් වන්නේ කෙසේද යන්න තේරුම් ගැනීමට තීරණාත්මක කරුණු මේවා යැයි මම සිතමි.

• REST ප්‍රොටෝකෝලය ස්වාධීනයි. එය HTTP සමඟ සම්බන්ධ නොවේ. ඔබට වෙබ් අඩවියක ftp සබැඳියක් අනුගමනය කළ හැකි තරමටම, REST යෙදුමකට ප්‍රමිතිගත URI යෝජනා ක්‍රමයක් ඇති ඕනෑම ප්‍රොටෝකෝලයක් භාවිතා කළ හැකිය.

• REST යනු CRUD සිට HTTP ක්‍රම සිතියම්ගත කිරීමක් නොවේ. ඒ පිළිබඳ සවිස්තරාත්මක පැහැදිලි කිරීමක් සඳහා මෙම පිළිතුර කියවන්න .

• REST ඔබ භාවිතා කරන කොටස් තරම් ප්‍රමිතිගත කර ඇත. HTTP හි ආරක්ෂාව සහ සත්‍යාපනය ප්‍රමිතිගත කර ඇත, එබැවින් HTTP හරහා REST කරන විට ඔබ භාවිතා කරන්නේ එයයි.

• බෝපාල් තොරව ඉතිරි නොවේ hypermedia හා HATEOAS . මෙයින් අදහස් කරන්නේ සේවාදායකයා යූආර්අයි පිවිසුම් ස්ථානය පමණක් දන්නා අතර සම්පත් විසින් සේවාදායකයා විසින් අනුගමනය කළ යුතු සම්බන්ධතා නැවත ලබා දිය යුතු බවයි. REST API එකකින් ඔබට කළ හැකි සෑම දෙයක් සඳහාම URI රටා ලබා දෙන එම විසිතුරු ලියකියවිලි උත්පාදක යන්ත්රය එම කරුණ සම්පූර්ණයෙන්ම මග හැරේ. ඔවුන් ප්‍රමිතිය අනුගමනය කළ යුතු දෙයක් ලේඛනගත කිරීම පමණක් නොව, ඔබ එය කරන විට, ඔබ ඒපීඅයි හි පරිණාමයේ එක් මොහොතකට සේවාදායකයා සම්බන්ධ කරයි, ඒපීඅයි හි කිසියම් වෙනස්කමක් ලේඛනගත කර යෙදිය යුතුය, නැත්නම් එය කැඩී යයි.

• REST යනු වෙබයේම වාස්තු විද්‍යාත්මක ශෛලියයි. ඔබ Stack Overflow වෙත ඇතුළු වූ විට, පරිශීලකයෙකු, ප්‍රශ්නයක් සහ පිළිතුරක් යනු කුමක්දැයි ඔබ දන්නවා, ඔබ මාධ්‍ය වර්ග දන්නවා, සහ වෙබ් අඩවිය ඔබට ඒවාට සබැඳි සපයයි. REST API එකද එසේ කළ යුතුය. REST සිදු කළ යුතු යැයි මිනිසුන් සිතන ආකාරයට අපි වෙබය නිර්මාණය කර ඇත්නම්, ප්‍රශ්න හා පිළිතුරු සඳහා සබැඳි සහිත මුල් පිටුවක් තිබීම වෙනුවට, අපට ස්ථිතික ලියකියවිලි තිබේ, එය ප්‍රශ්නයක් බැලීමට නම් ඔබ URI ගත යුතුය stackoverflow.com/questions/<id>, Question.id සමඟ හැඳුනුම්පත ප්‍රතිස්ථාපනය කර ඔබගේ බ්‍රව්සරයේ අලවන්න. එය විකාරයකි, නමුත් බොහෝ අය සිතන්නේ REST යනු එයයි.

මෙම අවසාන කරුණ ප්‍රමාණවත් ලෙස අවධාරණය කළ නොහැක. ඔබේ සේවාදායකයින් ප්‍රලේඛනවල සැකිලි වලින් යූආර්අයි ගොඩනඟන්නේ නම් සහ සම්පත් නිරූපණයන්හි සබැඳි නොලැබෙන්නේ නම්, එය REST නොවේ. REST හි කතුවරයා වන රෝයි ෆීල්ඩින් මෙම බ්ලොග් සටහනේ පැහැදිලි කළේය: REST APIs අධි-පෙළ මත පදනම් විය යුතුය .

ඉහත සඳහන් කරුණු මනසේ තබාගෙන, REST XML වලට පමණක් සීමා නොවිය හැකි අතර, වෙනත් ඕනෑම ආකෘතියකින් එය නිවැරදිව කිරීමට නම්, ඔබේ සබැඳි සඳහා යම් ආකෘතියක් සැලසුම් කර ප්‍රමිතිකරණය කළ යුතුය. හයිපර්ලින්ක්ස් XML හි සම්මත වේ, නමුත් JSON හි නොවේ. HAL වැනි JSON සඳහා කෙටුම්පත් ප්‍රමිතීන් ඇත.

අවසාන වශයෙන්, REST සෑම කෙනෙකුටම නොවේ. ඒ සඳහා සාක්ෂියක් වන්නේ බොහෝ දෙනා ඔවුන්ගේ ගැටළු REST ලෙස වැරදියට හඳුන්වන HTTP API සමඟ ඉතා හොඳින් විසඳන ආකාරයයි. REST සමහර විට, විශේෂයෙන් ආරම්භයේ දී කිරීම දුෂ්කර ය, නමුත් එය කාලයත් සමඟ සේවාදායකයාගේ පැත්තේ පහසු පරිණාමය සහ සේවාදායකයාගේ වෙනස්කම් වලට ඔරොත්තු දීමේ හැකියාව ඇත. ඔබට ඉක්මණින් හා පහසුවෙන් යමක් කිරීමට අවශ්‍ය නම්, REST නිවැරදිව ලබා ගැනීම ගැන කරදර නොවන්න. එය බොහෝ විට ඔබ සොයන දේ නොවේ. ඔබට වසර ගණනාවක් හෝ දශක ගණනාවක් අන්තර්ජාලය තුළ රැඳී සිටීමට අවශ්‍ය යමක් අවශ්‍ය නම්, REST ඔබ වෙනුවෙන් වේ.

RESTඑදිරිව SOAPවේ නොහැකි අහන්න අයිතිය ප්රශ්නයක්.

REST, මෙන් නොව SOAPවේ නොහැකි දක්වා ඇති ප්රොටොකෝලය.

RESTයනු ගෘහ නිර්මාණ ශිල්පීය හා නිර්මාණ ජාලය මත පදනම් වන මෘදුකාංග සැකසුම්.

RESTසංකල්ප සම්පත් ලෙස හැඳින්වේ. සම්පතක් නිරූපණය කිරීම අස්ථායි විය යුතුය. එය යම් මාධ්‍ය වර්ගයක් හරහා නිරූපණය කෙරේ. මාධ්ය වර්ග සමහරක් උදාහරණ ඇතුළත් XML, JSONහා RDF. සම්පත් හසුරුවනු ලබන්නේ සංරචක මගිනි. සංරචක සම්මත ඒකාකාර අතුරුමුහුණතක් හරහා සම්පත් ඉල්ලීම සහ හැසිරවීම. HTTP සම්බන්ධයෙන් ගත් කල, මෙම අතුරුමුහුණත සම්මත HTTP මෙහෙයුම් උදා සමන්විත GET, PUT, POST, DELETE.

අබ්දුල් අසීස් ප්රශ්නයට @ බව ආලෝකවත් වූ කරුණ RESTසහ HTTPබොහෝ විට එක පෙලට භාවිතා වේ. මෙයට මූලික වශයෙන් හේතු වී ඇත්තේ HTTP හි සරල බව සහ RESTful මූලධර්ම වලට එහි ස්වාභාවික සිතියම්කරණයයි.

මූලික REST මූලධර්ම

සේවාලාභී-සේවාදායක සන්නිවේදනය

සේවාලාභී-සේවාදායක ගෘහ නිර්මාණ ශිල්පය තුළ සැළකිලිමත් ලෙස වෙන්වීමක් ඇත. RESTful ශෛලිය තුළ ගොඩනගා ඇති සියලුම යෙදුම් ප්‍රතිපත්තිමය වශයෙන් සේවාදායක-සේවාදායක විය යුතුය.

අස්ථායි

සේවාදායකයා වෙත කරන සෑම සේවාදායක ඉල්ලීමකටම එහි තත්වය සම්පූර්ණයෙන් නිරූපණය කිරීම අවශ්‍ය වේ. කිසිදු සේවාදායක සන්දර්භයක් හෝ සේවාදායක සැසි තත්වයක් භාවිතා නොකර සේවාදායකයාගේ ඉල්ලීම සම්පූර්ණයෙන්ම තේරුම් ගැනීමට සේවාදායකයාට හැකි විය යුතුය. සියළුම රාජ්යයන් සේවාදායකයා මත තබා ගත යුතු බව එයින් කියවේ.

හැඹිලි කළ හැකි

හැඹිලි අවහිරතා භාවිතා කළ හැකි අතර එමඟින් ප්‍රතිචාර දත්ත හැඹිලි කළ හැකි හෝ හැඹිලි කළ නොහැකි ලෙස සලකුණු කිරීමට හැකි වේ. හැඹිලි කළ හැකි ලෙස සලකුණු කර ඇති ඕනෑම දත්තයක් පසුකාලීන ඉල්ලීමට ප්‍රතිචාරයක් ලෙස නැවත භාවිතා කළ හැකිය.

ඒකාකාර අතුරුමුහුණත

සියලුම සංරචක තනි ඒකාකාර අතුරු මුහුණතක් හරහා අන්තර් ක්‍රියා කළ යුතුය. සියලුම සංරචක අන්තර්ක්‍රියා මෙම අතුරුමුහුණත හරහා සිදුවන නිසා, විවිධ සේවාවන් සමඟ අන්තර්ක්‍රියා කිරීම ඉතා සරල ය. අතුරු මුහුණත එක හා සමානයි! ක්‍රියාත්මක කිරීමේ වෙනස්කම් හුදකලාව සිදු කළ හැකි බව මින් අදහස් වේ. ඒකාකාර අතුරුමුහුණත සැමවිටම නොවෙනස්ව පවතින නිසා එවැනි වෙනස්කම් මූලික සංරචක අන්තර්ක්‍රියා කෙරෙහි බලපාන්නේ නැත. එක් අවාසියක් නම් ඔබ අතුරු මුහුණත සමඟ සිරවී සිටීමයි. අතුරු මුහුණත වෙනස් කිරීමෙන් නිශ්චිත සේවාවක් සඳහා ප්‍රශස්තිකරණයක් ලබා දිය හැකි නම්, REST මෙය තහනම් කරන බැවින් ඔබට වාසනාව නැත. කෙසේ වෙතත්, දීප්තිමත් පැත්තෙන්, REST වෙබය සඳහා ප්‍රශස්තිකරණය කර ඇත, එබැවින් HTTP හරහා REST හි ඇදහිය නොහැකි තරම් ජනප්‍රියත්වයක්!

ඉහත සංකල්පයන් REST හි ලක්ෂණ නිර්වචනය කරන අතර REST ගෘහ නිර්මාණ ශිල්පය වෙබ් සේවා වැනි වෙනත් ගෘහ නිර්මාණ වලින් වෙන්කර හඳුනා ගනී. REST සේවාවක් යනු වෙබ් සේවාවක් බව සටහන් කිරීම ප්‍රයෝජනවත් වේ, නමුත් වෙබ් සේවාවක් අනිවාර්යයෙන්ම REST සේවාවක් නොවේ.

මෙම බ්ලොග් අඩවිය බලන්න පශ්චාත් මත බෝපාල් නිර්මාණ ප්රතිපත්ති පිළිබඳ වැඩි විස්තර සඳහා බෝපාල් හා ඉහත සඳහන් උණ්ඩ.

සංස්කරණය කරන්න: අදහස් මත පදනම්ව අන්තර්ගතය යාවත්කාලීන කරන්න

SOAP ( සරල වස්තු ප්‍රවේශ ප්‍රොටොකෝලය ) සහ REST ( නියෝජන රාජ්‍ය මාරුව ) යන දෙකම ඔවුන්ගේ ආකාරයට ලස්සනයි. එබැවින් මම ඒවා සංසන්දනය නොකරමි. ඒ වෙනුවට, මම REST භාවිතා කිරීමට කැමති විට සහ SOAP භාවිතා කරන විට, පින්තූරය නිරූපණය කිරීමට උත්සාහ කරමි.

ගෙවීම යනු කුමක්ද?

අන්තර්ජාලය හරහා දත්ත යවන විට, සම්ප්‍රේෂණය වන සෑම ඒකකයකටම ශීර්ෂ තොරතුරු සහ සත්‍ය දත්ත යවනු ලැබේ. ශීර්ෂකය පැකට්ටුවේ ප්‍රභවය සහ ගමනාන්තය හඳුනා ගන්නා අතර සත්‍ය දත්ත ගෙවීම් භාරය ලෙස හැඳින්වේ . පොදුවේ ගත් කල, ගෙවීම යනු යෙදුමක් වෙනුවෙන් ගෙන යන දත්ත සහ ගමනාන්ත පද්ධතියට ලැබෙන දත්ත ය.

දැන්, උදාහරණයක් ලෙස, මට ටෙලිග්‍රෑම් එකක් යැවිය යුතු අතර, විදුලි පණිවුඩයේ පිරිවැය සමහර වචන මත රඳා පවතින බව අපි කවුරුත් දනිමු.

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

<name>Arin</name>

හෝ

"name": "Arin"

එකම පිළිතුර නියෝජනය කරන දෙකම පිරිවැය සම්බන්ධයෙන් ලාභදායී වුවද ඔබේ පිළිතුර දෙවැන්න බව මම දනිමි.

එබැවින් මම කියන්නට උත්සාහ කරන්නේ, ජාලය හරහා දත්ත JSON ආකෘතියෙන් යැවීම, ගෙවීම් සම්බන්ධයෙන් XML ආකෘතියෙන් යැවීමට වඩා ලාභදායී බවයි .

SOAP වලට වඩා REST හි පළමු ප්‍රතිලාභය හෝ වාසි මෙන්න . SOAP XML සඳහා පමණක් සහය දක්වයි, නමුත් REST පෙළ, JSON, XML වැනි විවිධ ආකෘතීන්ට සහය දක්වයි. තවද අපි දැනටමත් දන්නවා, අපි Json භාවිතා කරන්නේ නම් නියත වශයෙන්ම අපි ගෙවීම් සම්බන්ධයෙන් වඩා හොඳ තැනක සිටිමු.

දැන්, SOAP එකම XML සඳහා සහය දක්වයි, නමුත් එහි වාසි ද ඇත.

ඇත්තටම! කෙසේද?

SOAP ආකාර තුනකින් XML මත රඳා පවතී ලියුම් කවරය - එය පණිවිඩයේ ඇති දේ සහ එය සකසන ආකාරය නිර්වචනය කරයි.

දත්ත වර්ග සඳහා කේතීකරණ නීති මාලාවක්, අවසානයේදී ක්‍රියා පටිපාටියේ පිරිසැලසුම ඇමතුම් සහ ප්‍රතිචාර එක්රැස් කරන ලදි.

මෙම ලියුම් කවරය ප්‍රවාහනය (HTTP / HTTPS) හරහා යවනු ලබන අතර, RPC (දුරස්ථ ක්‍රියා පටිපාටිය ඇමතුමක්) ක්‍රියාත්මක වන අතර, ලියුම් කවරය XML ආකෘතිගත ලේඛනයක තොරතුරු සමඟ ආපසු එවනු ලැබේ.

වැදගත් කරුණ නම් SOAP හි එක් වාසියක් වන්නේ “සාමාන්‍ය” ප්‍රවාහනය භාවිතා කිරීමයි, නමුත් REST HTTP / HTTPS භාවිතා කරයි . ඉල්ලීම යැවීම සඳහා SOAP හට ඕනෑම ප්‍රවාහනයක් භාවිතා කළ හැකි නමුත් REST ට නොහැකි ය. ඉතින් මෙන්න අපට SOAP භාවිතා කිරීමේ වාසියක් ලැබුණා.

ඉහත ඡේදයේ මා දැනටමත් සඳහන් කර ඇති පරිදි “REST HTTP / HTTPS භාවිතා කරයි” , එබැවින් මෙම වචන ගැන ටිකක් ගැඹුරට යන්න.

අපි HTTP හරහා REST ගැන කතා කරන විට, HTTP යොදන සියලුම ආරක්ෂක පියවරයන් උරුම වී ඇති අතර මෙය ප්‍රවාහන මට්ටමේ ආරක්ෂාව ලෙස හැඳින්වෙන අතර එය පණිවිඩ සුරක්ෂිත කරන්නේ එය කම්බි තුළ සිටියදී පමණක් වන නමුත් ඔබ එය අනෙක් පැත්තට භාර දුන් පසු ඔබ දන්නේ නැත දත්ත සැකසෙන සැබෑ ස්ථානයට පැමිණීමට පෙර එය අදියර කීයක් හරහා යා යුතුද? ඇත්ත වශයෙන්ම, එම සියලු අදියරයන් HTTP ට වඩා වෙනස් දෙයක් භාවිතා කළ හැකිය. ඉතින් රෙස්ට් සම්පූර්ණයෙන්ම ආරක්ෂිත නැහැ නේද?

නමුත් SOAP SSL සඳහා REST මෙන් සහය දක්වයි. ඊට අමතරව එය WS-Security සඳහාද සහාය වන අතර එමඟින් සමහර ව්‍යවසාය ආරක්ෂක අංග එකතු කරයි. WS-Security පණිවිඩය නිර්මාණය කිරීමෙන් එහි පරිභෝජනයට ආරක්ෂාව සපයයි . එබැවින් ප්‍රවාහන මට්ටමේ ආරක්ෂාව සඳහා WS-Security භාවිතා කිරීමෙන් වළක්වා ගත හැකි ඕනෑම අඩුපාඩුවක්.

ඒ හැරුණු විට, REST එහි HTTP ප්‍රොටෝකෝලය මගින් සීමා කර ඇති බැවින් එහි ගනුදෙනු සහාය ACID අනුකූල නොවන අතර බෙදා හරින ලද අන්තර්ජාතික සම්පත් හරහා අදියර දෙකක බැඳීමක් ලබා දිය නොහැක.

නමුත් කෙටි කාලීන ගනුදෙනු සඳහා ACID පදනම් කරගත් ගනුදෙනු කළමනාකරණය සහ දිගුකාලීන ගනුදෙනු සඳහා වන්දි පදනම් කරගත් ගනුදෙනු කළමනාකරණය යන දෙකටම SOAP සතුව පුළුල් සහයෝගයක් ඇත. බෙදා හරින ලද සම්පත් හරහා අදියර දෙකක කැපවීමට ද එය සහාය වේ.

මම කිසිදු නිගමනයකට එළඹෙන්නේ නැත, නමුත් ආරක්ෂාව, ගනුදෙනු යනාදිය ප්‍රධාන වශයෙන් සැලකිලිමත් වන අතර මම SOAP මත පදනම් වූ වෙබ් සේවාවට කැමැත්තෙමි.

මෙන්න "ජාවා ඊඊ 6 නිබන්ධනය" ඔවුන් පවසා ඇත්තේ පහත සඳහන් කොන්දේසි සපුරාලන විට RESTful නිර්මාණයක් සුදුසු විය හැකි බවයි . බලන්න.

ඔබ මගේ පිළිතුර කියවීමෙන් සතුටක් ලැබුවා යැයි සිතමි.

REST ( RE ඉදිරිපත් කිරීම එස් ටේට් ටී ransfer)
RE අයුරු එස් ටේට් වස්තුවක ඇත ටී ransferred බෝපාල් අපි වස්තූන් යවන්න එපා එනම්, අප වස්තූන් රාජ්ය යවන්න. REST යනු වාස්තු විද්‍යාත්මක ශෛලියකි. එය SOAP වැනි බොහෝ ප්‍රමිතීන් නිර්වචනය නොකරයි. REST යනු දත්ත මත CRUD මෙහෙයුම් හැසිරවීම සඳහා අන්තර්ජාලය හරහා පොදු API (එනම් ෆේස්බුක් API, ගූගල් සිතියම් API) නිරාවරණය කිරීමයි. REST අවධානය යොමු කර ඇත්තේ තනි ස්ථාවර අතුරු මුහුණතක් හරහා නම් කරන ලද සම්පත් වෙත ප්‍රවේශ වීම සඳහා ය.

SOAP ( එස් imple සාමාන්ය bject A ccess P rotocol)
SOAP තමන්ගේම ප්‍රොටෝකෝලයක් ගෙන එන අතර සේවා තර්කන (දත්ත නොවේ) කොටස් ලෙස නිරාවරණය කිරීම කෙරෙහි අවධානය යොමු කරයි. SOAP මෙහෙයුම් නිරාවරණය කරයි. SOAP අවධානය යොමු කර ඇත්තේ නම් කරන ලද මෙහෙයුම් වලට ප්‍රවේශ වීම සඳහා වන අතර, සෑම මෙහෙයුමක්ම යම් ව්‍යාපාර තර්කනයක් ක්‍රියාත්මක කරයි. SOAP සාමාන්‍යයෙන් වෙබ් සේවා ලෙස හැඳින්වුවද මෙය වැරදි නාමයකි. වෙබය සමඟ යමක් කිරීමට SOAP සතුව ඇත්තේ ඉතා අල්ප ප්‍රමාණයකි. REST යූආර්අයි සහ එච්ටීටීපී මත පදනම්ව සත්‍ය වෙබ් සේවා සපයයි .

REST ඇයි?

• REST සම්මත HTTP භාවිතා කරන බැවින් එය වෙන කවරදාටත් වඩා සරල ය.
• REST ක්‍රියාත්මක කිරීම පහසුය, අඩු කලාප පළලක් සහ සම්පත් අවශ්‍ය වේ.
• SOAP විසින් XML සඳහා පමණක් අවසර දී ඇති පරිදි REST විවිධ දත්ත ආකෘති වලට අවසර දෙයි.
• JSON සඳහා වන සහාය නිසා REST බ්‍රව්සර් සේවාදායකයින් සඳහා වඩා හොඳ සහාය ලබා දේ.
• REST වඩා හොඳ කාර්ය සාධනයක් සහ පරිමාණයක් ඇත. REST කියවීම් හැඹිලිගත කළ හැකිය, SOAP පදනම් කරගත් කියවීම් හැඹිලි කළ නොහැක.
• ආරක්ෂාව ප්‍රධාන කරුණක් නොවන්නේ නම් සහ අපට සීමිත සම්පත් තිබේ නම්. නැතහොත් අපට වෙනත් සංවර්ධකයින්ට පහසුවෙන් භාවිතා කළ හැකි API එකක් නිර්මාණය කිරීමට අවශ්‍ය නම් අපි REST සමඟ යා යුතුය.
• අපට අස්ථායි CRUD මෙහෙයුම් අවශ්‍ය නම් REST සමඟ යන්න.
• REST බහුලව භාවිතා වන්නේ සමාජ මාධ්‍ය, වෙබ් චැට්, ජංගම සේවා සහ ගූගල් සිතියම් වැනි පොදු API වල ය.
• ඉල්ලීම් ශීර්ෂ පරාමිතිය "පිළිගන්න" application/xmlහෝ application/jsonPOST සහ /user/1234.jsonහෝ GET සඳහා ඉල්ලීම් ශීර්ෂ පරාමිතිය මත පදනම්ව, එකම සම්පතක් සඳහා විවිධ මාධ්‍ය ටයිප් නැවත ලබා දෙයි./user/1234.xml ලබා ගන්න සඳහා.
• REST සේවාවන් යන්නෙන් අදහස් කරන්නේ සේවාදායකයාගේ පාර්ශවීය යෙදුම වන අතර අවසාන පරිශීලකයා කෙලින්ම නොවේ.
• ST හි REST පැමිණෙන්නේ S tate T ransfer වෙතින් ය. ඔබ සේවාදායකය ගබඩා කර තබනවා වෙනුවට රාජ්‍යය මාරු කරයි, මෙය REST සේවාවන් පරිමාණය කළ හැකි ය.

SOAP ඇයි?

• SOAP ක්‍රියාත්මක කිරීම එතරම් පහසු නොවන අතර වැඩි කලාප පළලක් සහ සම්පත් අවශ්‍ය වේ.
• REST හා සසඳන විට SOAP පණිවිඩ ඉල්ලීම මන්දගාමීව ක්‍රියාවට නංවන අතර එය වෙබ් හැඹිලි යාන්ත්‍රණය භාවිතා නොකරයි.
• WS- ආරක්ෂාව: SOAP SSL සඳහා සහය දක්වන අතර (REST මෙන්) එය WS-Security සඳහාද සහාය වන අතර එමඟින් සමහර ව්‍යවසාය ආරක්ෂක අංග එකතු කරයි.
• WS-AtomicTransaction: සේවාවක් හරහා ACID ගනුදෙනු අවශ්‍යයි, ඔබට SOAP අවශ්‍ය වේ.
• WS-ReliableMessaging: ඔබේ යෙදුමට අසමමුහුර්ත සැකසුම් සහ සහතික කළ මට්ටමේ විශ්වසනීයත්වයක් සහ ආරක්ෂාවක් අවශ්‍ය නම්. විවේකයට සම්මත පණිවුඩකරණ පද්ධතියක් නොමැති අතර නැවත උත්සාහ කිරීමෙන් සන්නිවේදන අසමත්වීම් සමඟ ගනුදෙනු කිරීම සේවාදායකයින් අපේක්ෂා කරයි.
• ආරක්ෂාව ප්‍රධාන කරුණක් නම් සහ සම්පත් සීමිත නොවේ නම් අපි SOAP වෙබ් සේවා භාවිතා කළ යුතුය. ගෙවීම් දොරටු, මූල්‍ය හා විදුලි සංදේශ සම්බන්ධ කටයුතු සඳහා අපි වෙබ් සේවාවක් නිර්මාණය කරන්නේ නම්, ඉහළ ආරක්ෂාවක් අවශ්‍ය බැවින් අපි SOAP සමඟ යා යුතුය.

source1
source2

විවේකය සහ සබන් අතර වෙනස

SOAP

1. SOAP යනු ප්‍රොටෝකෝලයකි.
2. SOAP යනු සරල වස්තු ප්‍රවේශ ප්‍රොටොකෝලයයි.
3. SOAP හට REST භාවිතා කළ නොහැක මන්ද එය ප්‍රොටෝකෝලයකි.
4. ව්‍යාපාර තර්කනය හෙළිදරව් කිරීම සඳහා SOAP සේවා අතුරුමුහුණත් භාවිතා කරයි.
5. SOAP විසින් අනුගමනය කළ යුතු ප්‍රමිතීන් නිර්වචනය කරයි.
6. SOAP හට REST ට වඩා කලාප පළලක් සහ සම්පතක් අවශ්‍ය වේ.
7. SOAP තමන්ගේ ආරක්ෂාව අර්ථ දක්වයි.
8. SOAP විසින් XML දත්ත ආකෘතියට පමණක් අවසර දෙයි.
9. SOAP REST ට වඩා අඩු කැමැත්තක් දක්වයි.

REST

1. REST යනු වාස්තු විද්‍යාත්මක ශෛලියකි.
2. REST යනු නියෝජිත රාජ්‍ය මාරුවයි.
3. REST හට SOAP වෙබ් සේවා භාවිතා කළ හැක්කේ එය සංකල්පයක් වන නිසා සහ HTTP, SOAP වැනි ඕනෑම ප්‍රොටෝකෝලයක් භාවිතා කළ හැකි බැවිනි.
4. ව්‍යාපාර තර්කනය නිරාවරණය කිරීමට REST URI භාවිතා කරයි.
5. REST SOAP වැනි ප්‍රමිති නිර්වචනය නොකරයි.
6. REST සඳහා SOAP ට වඩා අඩු කලාප පළලක් සහ සම්පතක් අවශ්‍ය වේ.
7. RESTful වෙබ් සේවාවන්ට යටින් පවතින ප්‍රවාහනයෙන් ආරක්ෂක පියවරයන් උරුම වේ.
8. සරල පෙළ, HTML, XML, JSON වැනි විවිධ දත්ත ආකෘතීන් සඳහා REST අවසර දෙයි.
9. SOAP ට වඩා REST වඩා කැමති.

වැඩි විස්තර සඳහා කරුණාකර මෙහි බලන්න

IMHO ඔබට වෙනස් කරුණු දෙකක් ඇති SOAP සහ REST සංසන්දනය කළ නොහැක.

SOAP යනු ප්‍රොටෝකෝලයක් වන අතර REST යනු මෘදුකාංග වාස්තු විද්‍යාත්මක රටාවකි. SOAP vs REST සඳහා අන්තර්ජාලයේ වැරදි වැටහීමක් තිබේ .

SOAP විසින් XML මත පදනම් වූ පණිවිඩ ආකෘතිය අර්ථ දක්වන්නේ වෙබ් සේවා සක්‍රීය යෙදුම් අන්තර්ජාලය හරහා එකිනෙකා සන්නිවේදනය කිරීමට භාවිතා කරන බැවිනි. එසේ කිරීම සඳහා යෙදුම් කොන්ත්‍රාත්තුව, දත්ත කට්ටල ආදිය පිළිබඳ පූර්ව දැනුමක් අවශ්‍ය වේ.

REST යනු URL එකකින් සේවාදායකයක තත්වය (සම්පත් ලෙස) නිරූපණය කරයි.එය අස්ථායි වන අතර සේවාදායකයින්ට හයිපර්මීඩියා පිළිබඳ අවබෝධයෙන් ඔබ්බට සේවාදායකයා සමඟ අන්තර් ක්‍රියා කිරීමට පූර්ව දැනුමක් නොතිබිය යුතුය.

පළමුවෙන්ම: නිල වශයෙන්, නිවැරදි ප්‍රශ්නය web services + WSDL + SOAPඑදිරිව REST.

මක්නිසාද යත්, වෙබ් සේවාව ලිහිල් අර්ථයෙන් භාවිතා වුවද , වෙබ් පිටු වෙනුවට දත්ත මාරු කිරීම සඳහා HTTP ප්‍රොටෝකෝලය භාවිතා කරන විට , නිල වශයෙන් එය එම අදහසෙහි නිශ්චිත ආකාරයකි. අර්ථ දැක්වීම අනුව, REST යනු "වෙබ් සේවාව" නොවේ.

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

දැනටමත් තාක්ෂණික පිළිතුරු ඇත, එබැවින් මම යම් බුද්ධියක් ලබා දීමට උත්සාහ කරමි.

වෙනත් ක්‍රමලේඛන භාෂාවකින් ක්‍රියාත්මක කරන දුරස්ථ පරිගණකයක ශ්‍රිතයක් ඇමතීමට ඔබට අවශ්‍ය යැයි කියමු (මෙය බොහෝ විට දුරස්ථ ක්‍රියා පටිපාටිය ඇමතුම් / ආර්පීසී ලෙස හැඳින්වේ ). ශ්‍රිතය එය ලියූ පුද්ගලයා විසින් සපයන ලද විශේෂිත URL එකකින් සොයාගත හැකි යැයි උපකල්පනය කරන්න. ඔබට (කෙසේ හෝ) එයට පණිවිඩයක් යැවිය යුතු අතර යම් ප්‍රතිචාරයක් ලබා ගත යුතුය. එබැවින් සලකා බැලිය යුතු ප්‍රධාන ප්‍රශ්න දෙකක් තිබේ.

• ඔබ යැවිය යුතු පණිවිඩයේ ආකෘතිය කුමක්ද?
• පණිවිඩය නැවත නැවතත් ඉදිරියට ගෙන යා යුත්තේ කෙසේද?

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

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

මෙම සමස්ත ප්‍රවේශයේ ප්‍රධාන අදහස නම් ඔබ ශ්‍රිතයකට URL එකක් සිතියම් ගත කිරීමයි , එනම් ක්‍රියාවකට ය . එබැවින්, ඔබට යම් සේවාදායකයක ගනුදෙනුකරුවන්ගේ ලැයිස්තුවක් තිබේ නම්, ඔබට එකක් බැලීමට / යාවත්කාලීන කිරීමට / මකා දැමීමට අවශ්‍ය නම්, ඔබට URL 3 ක් තිබිය යුතුය:

• myapp/read-customer පණිවිඩයේ ශරීරය තුළ, කියවිය යුතු පාරිභෝගිකයාගේ හැඳුනුම්පත ලබා දෙන්න.
• myapp/update-customer ශරීරය තුළ, පාරිභෝගිකයාගේ හැඳුනුම්පත මෙන්ම නව දත්තද ලබා දෙන්න
• myapp/delete-customer සහ ශරීරයේ ඇති හැඳුනුම්පත

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

එබැවින්, REST ප්‍රවේශය සමඟ, පාරිභෝගික අංකය 12 URL හි සොයාගත හැකිය myapp/customers/12. පාරිභෝගික දත්ත බැලීමට, ඔබ GET ඉල්ලීමක් සමඟ URL යතුර ඔබන්න. එය මකා දැමීමට, එකම URL, DELETE ක්‍රියාපදයක් සමඟ. එය යාවත්කාලීන කිරීම සඳහා, නැවතත්, POST ක්‍රියාපදයක් සහිත එකම URL එක සහ ඉල්ලීම් ශරීරයේ නව අන්තර්ගතය.

සේවාවක් සැබවින්ම රෙස්ට්ෆුල් ලෙස සැලකීමට සපුරාලිය යුතු අවශ්‍යතා පිළිබඳ වැඩි විස්තර සඳහා, රිචඩ්සන් පරිණත ආකෘතිය බලන්න . ලිපිය උදාහරණ සපයන අතර, වඩාත් වැදගත් ලෙස, (ඊනියා) SOAP සේවාවක් මට්ටම් -0 REST සේවාවක් වන්නේ මන්දැයි පැහැදිලි කරයි (කෙසේ වෙතත්, මට්ටම -0 යන්නෙන් අදහස් කරන්නේ මෙම ආකෘතියට අඩු අනුකූලතාවයක් ඇති නමුත් එය අහිතකර නොවන අතර එය තවමත් ප්‍රයෝජනවත් වේ බොහෝ අවස්ථාවල දී).

දැනටමත් බොහෝ පිළිතුරු වලින් ආවරණය කර ඇති තවත් බොහෝ දේ අතර, SOAP මඟින් කොන්ත්‍රාත්තුවක් නිර්වචනය කිරීමට හැකි බව මම අවධාරණය කරමි, සහාය දක්වන මෙහෙයුම්, සංකීර්ණ වර්ග ආදිය නිර්වචනය කරන WSDL, SOAP මෙහෙයුම් සඳහා නැඹුරු වන නමුත් REST සම්පත් මත පදනම් වේ. පුද්ගලිකව මම අභ්‍යන්තර ව්‍යවසාය යෙදුම් අතර සංකීර්ණ අතුරුමුහුණත් සඳහා SOAP සහ බාහිර ලෝකය සමඟ පොදු, සරල, අස්ථායි අතුරුමුහුණත් සඳහා REST තෝරා ගනිමි.

සඳහා එකතු කිරීම:

++ REST වෙත ළඟා වන විට බොහෝ විට සිදු වන අත්වැරැද්දක් නම්, එය “URL සහිත වෙබ් සේවා” ලෙස සිතීමයි - REST යනු SOAP වැනි තවත් දුරස්ථ ක්‍රියා පටිපාටි ඇමතුමක් (RPC) යාන්ත්‍රණයක් ලෙස සිතීම, නමුත් සරල HTTP URL හරහා සහ SOAP හි අධික ලෙස තොරව XML නාම අවකාශ.

++ ඊට පටහැනිව, REST හට RPC සමඟ එතරම් සම්බන්ධයක් නැත. ආර්පීසී යනු සේවා නැඹුරු වන අතර ක්‍රියාවන් හා ක්‍රියාපද කෙරෙහි අවධානය යොමු කර ඇති අතර, REST යනු සම්පත් නැඹුරු වන අතර යෙදුමකින් සමන්විත කරුණු සහ නාම පද අවධාරණය කරයි.

මෙම පිළිතුරු බොහොමයක් REST සඳහා සම්පූර්ණයෙන්ම මූලික වන හයිපර්මීඩියා පාලක (HATEOAS) සඳහන් කිරීමට සම්පූර්ණයෙන්ම අමතක වී ඇත. තවත් කිහිප දෙනෙක් එය ස්පර්ශ කළ නමුත් එය එතරම් හොඳින් පැහැදිලි කළේ නැත.

මෙම ලිපියෙන් විශේෂිත SOAP විශේෂාංග මත වල් පැලෑටිවලට නොගොස් සංකල්ප අතර වෙනස පැහැදිලි කළ යුතුය.