SOAP un REST (atšķirības)

Diemžēl par REST ir daudz nepareizas informācijas un maldīgu priekšstatu. Tos atspoguļo ne tikai jūsu jautājums un @cmd atbilde, bet arī lielākā daļa ar šo tēmu saistīto Stack Overflow jautājumu un atbilžu. SOAP un REST nevar tieši salīdzināt, jo pirmais ir protokols (vai vismaz cenšas tāds būt), bet otrais ir arhitektūras stils. Iespējams, tas ir viens no neskaidrību avotiem, jo cilvēki par REST mēdz saukt jebkuru HTTP API, kas nav SOAP. Nedaudz pavirzoties uz priekšu un mēģinot veikt salīdzinājumu, galvenā atšķirība starp SOAP un REST ir klienta un servera implementācijas sasaistes pakāpe. SOAP klients darbojas kā pielāgota darbvirsmas lietojumprogramma, kas ir cieši saistīta ar serveri. Starp klientu un serveri ir stingrs līgums, un ir sagaidāms, ka viss sabojāsies, ja kāda no pusēm kaut ko mainīs. Pēc jebkādām izmaiņām ir nepieciešami pastāvīgi atjauninājumi, bet ir vieglāk pārliecināties, vai līgums tiek ievērots. REST klients ir vairāk līdzīgs pārlūkam. Tas ir vispārīgs klients, kas prot izmantot protokolu un standartizētas metodes, un lietojumprogrammai ir jāiekļaujas tajā. Jūs nepārkāpjat protokola standartus, radot papildu metodes, jūs izmantojat standarta metodes un veidojat darbības ar tām savā multivides tipā. Ja tas tiek darīts pareizi, ir mazāka sasaiste, un izmaiņas var tikt risinātas elastīgāk. Klientam ir jāievada REST pakalpojums, nemaz nezinot API, izņemot ieejas punktu un multivides tipu. SOAP gadījumā klientam ir nepieciešamas iepriekšējas zināšanas par visu, ko tas izmantos, pretējā gadījumā tas pat nesāks mijiedarbību. Turklāt REST klientu var paplašināt ar kodu pēc pieprasījuma, ko nodrošina pats serveris, klasisks piemērs ir JavaScript kods, ko izmanto, lai vadītu mijiedarbību ar citu pakalpojumu klienta pusē. Manuprāt, šie ir būtiskākie punkti, lai saprastu, kas ir REST un ar ko tas atšķiras no SOAP:

• REST ir neatkarīgs no protokola. Tas nav saistīts ar HTTP. Gluži tāpat kā jūs varat sekot ftp saitei tīmekļa vietnē, REST lietojumprogramma var izmantot jebkuru protokolu, kuram ir standartizēta URI shēma.
• REST nav CRUD attiecināšana uz HTTP metodēm. Lasiet šo atbildi, lai saņemtu detalizētu skaidrojumu par šo jautājumu.
• REST ir tikpat standartizēts kā detaļas, ko izmantojat. HTTP drošība un autentifikācija ir standartizēta, tāpēc to arī izmantojiet, izmantojot REST, izmantojot HTTP.
• REST nav REST bez hypermedia un HATEOAS. Tas nozīmē, ka klients zina tikai ieejas punkta URI, un resursiem ir jāatgriež saites, kas klientam ir jāseko. Tie iedomātie dokumentācijas ģeneratori, kas sniedz URI paraugus visam, ko var darīt REST API, pilnībā nesaprot būtību. Tie ne tikai dokumentē kaut ko, kam vajadzētu sekot standartam, bet, to darot, jūs piesaistāt klientu vienam konkrētam API evolūcijas brīdim, un jebkuras izmaiņas API ir jādokumentē un jāpiemēro, citādi tas sabojās.
• REST ir paša tīmekļa arhitektūras stils. Ieejot vietnē Stack Overflow, jūs zināt, kas ir lietotājs, jautājums un atbilde, jūs zināt mediju veidus, un tīmekļa vietne jums nodrošina saites uz tiem. REST API ir jādara tas pats. Ja mēs veidotu tīmekli tā, kā cilvēki domā, ka REST ir jādara, tā vietā, lai izveidotu mājas lapu ar saitēm uz Jautājumiem un Atbildēm, mums būtu statiska dokumentācija, kurā būtu paskaidrots, ka, lai apskatītu jautājumu, ir jāņem URI stackoverflow.com/questions/, jāaizstāj id ar Question.id un jāievieto tas savā pārlūkprogrammā. Tā ir muļķība, bet daudzi cilvēki domā, ka REST ir tieši tas. Šo pēdējo punktu nevar pietiekami uzsvērt. Ja jūsu klienti veido URI no dokumentācijā esošajiem šabloniem un nesaņem saites resursu reprezentācijās, tas nav REST. REST autors Rojs Fīldings (Roy Fielding) šajā bloga ierakstā to ir paskaidrojis: REST API ir jābūt hipertekstuāliem. Paturot prātā iepriekš minēto, jūs sapratīsiet, ka, lai gan REST, iespējams, nav ierobežots ar XML, lai to pareizi veiktu ar jebkuru citu formātu, jums būs jāizstrādā un jāstandartizē kāds saišu formāts. Hipersaites ir standarta XML, bet ne JSON. JSON ir standartu projekti, piemēram, HAL. Visbeidzot, REST nav domāts visiem, un pierādījums tam ir tas, ka lielākā daļa cilvēku ļoti labi atrisina savas problēmas ar HTTP API, ko viņi kļūdaini sauc par REST, un nekad neriskē tālāk par to. REST dažreiz ir grūti, īpaši sākumā, bet laika gaitā tas atmaksājas ar vieglāku attīstību servera pusē un klienta'elastību pret izmaiņām. Ja jums kaut kas ir jādara ātri un viegli, necentieties pareizi izmantot REST. Iespējams, tas nav tas, ko jūs meklējat. Ja jums vajag kaut ko, kas būs tiešsaistē gadiem vai pat gadu desmitiem, tad REST ir domāts tieši jums.

REST vs SOAP ir ne pareizais jautājums.

REST atšķirībā no SOAP nav protokols.

REST ir arhitektūras stils un uz tīklu balstītas programmatūras arhitektūras projekts.

REST koncepcijas tiek sauktas par resursiem. Resursu reprezentācijai jābūt bezstāvokļa. Tas tiek attēlots, izmantojot kādu informācijas nesēja tipu. Daži mediju tipu piemēri ir XML, JSON un RDF. Ar resursiem manipulē komponenti. Komponenti pieprasa un apstrādā resursus, izmantojot standarta vienotu saskarni. HTTP gadījumā šo saskarni veido standarta HTTP operācijas, piemēram, GET, PUT, POST, DELETE.

@Abdulaziz'jautājums patiešām izgaismo faktu, ka REST un HTTP bieži tiek izmantoti kopā. Tas galvenokārt ir saistīts ar HTTP vienkāršību un tā ļoti dabisko pielīdzināšanu RESTful principiem.

REST pamatprincipi

Klienta un servera saziņa

Klienta-servera arhitektūrās ir ļoti skaidri nodalītas rūpes. Visām lietojumprogrammām, kas veidotas REST stilā, principā arī jābūt klienta-servera lietojumprogrammām.

Bezstāvokļa

Katram klienta pieprasījumam serverim ir pilnībā jāpārstāv tā stāvoklis. Serverim jāspēj pilnībā saprast klienta pieprasījumu, neizmantojot servera kontekstu vai servera sesijas stāvokli. No tā izriet, ka viss stāvoklis ir jāglabā klientam.

Vešatmiņa

Var izmantot kešatmiņas ierobežojumus, tādējādi ļaujot atbildes datus atzīmēt kā kešējamus vai ne-kešējamus. Jebkurus datus, kas atzīmēti kā kešējami, var atkārtoti izmantot kā atbildi uz to pašu nākamo pieprasījumu.

Viendabīga saskarne

Visām sastāvdaļām jāsadarbojas, izmantojot vienotu vienotu saskarni. Tā kā visa komponentu mijiedarbība notiek, izmantojot šo saskarni, mijiedarbība ar dažādiem pakalpojumiem ir ļoti vienkārša. Saskarne ir vienāda! Tas arī nozīmē, ka implementācijas izmaiņas var veikt izolēti. Šādas izmaiņas neietekmēs komponentu mijiedarbību, jo vienotā saskarne vienmēr ir nemainīga. Viens no trūkumiem ir tas, ka jūs esat piesaistīts saskarnei. Ja, mainot saskarni, varētu optimizēt konkrētu pakalpojumu, jums nav paveicies, jo REST to aizliedz. Tomēr, no otras puses, REST ir optimizēts tīmeklim, tāpēc REST ir neticami populārs HTTP!

Iepriekš minētie jēdzieni raksturo REST definējošās īpašības un atšķir REST arhitektūru no citām arhitektūrām, piemēram, tīmekļa pakalpojumiem. Ir lietderīgi atzīmēt, ka REST pakalpojums ir tīmekļa pakalpojums, bet tīmekļa pakalpojums ne vienmēr ir REST pakalpojums.

Sīkāku informāciju par REST un iepriekš minētajiem punktiem skatiet šajā bloga ierakstā par REST projektēšanas principiem.

EDIT: atjaunināt saturu, pamatojoties uz komentāriem.

SOAP (Pareizais objektu piekļuves protokols) un REST (Prezentācijas stāvokļa pārnese) ir savā ziņā skaisti. Tāpēc es tos nesalīdzināšu. Tā vietā es mēģinu parādīt, kādos gadījumos man labāk patīk izmantot REST un kādos SOAP.

Kas ir komerckrava?

Kad dati tiek sūtīti internetā, katra pārraidītā vienība ietver gan galvenes informāciju, gan faktiskos sūtītos datus. Rādītājs identificē paketes avotu un galamērķi, savukārt faktiskie dati tiek saukti par lietderīgo slodzi**. Kopumā lietderīgā slodze ir dati, kas tiek pārnesti lietojumprogrammas vārdā, un dati, ko saņem galamērķa sistēma.

Piemēram, man ir jānosūta telegramma, un mēs visi zinām, ka telegrammas izmaksas būs atkarīgas no dažiem vārdiem.

Tāpēc sakiet man, kuru no turpmāk minētajiem diviem ziņojumiem ir lētāk nosūtīt?

Arin

vai

"name": "Arin"

Es zinu, ka jūsu atbilde būs otrais, lai gan abi ir vienāda ziņa, otrais ir lētāks attiecībā uz izmaksām.

Tāpēc es cenšos teikt, ka sūtīt datus pa tīklu JSON formātā ir lētāk nekā XML formātā attiecībā uz datu slodzi.

Šī ir pirmā priekšrocība vai REST priekšrocības salīdzinājumā ar SOAP. SOAP atbalsta tikai XML, bet REST atbalsta dažādus formātus, piemēram, tekstu, JSON, XML utt. Un mēs jau zinām, ka, ja mēs izmantosim Json, tad noteikti būsim labākā situācijā attiecībā uz lietderīgo slodzi.

Tagad SOAP atbalsta tikai XML, bet arī tam ir savas priekšrocības**.

**Tiešām! Kā?

SOAP balstās uz XML trīs veidos Aploksne - tā nosaka, kas ir ziņojumā un kā to apstrādāt.

Datu tipu kodēšanas noteikumu kopums un, visbeidzot, procedūras izsaukumu un apkopoto atbilžu izkārtojums.

Šī aploksne tiek nosūtīta, izmantojot transportu (HTTP/HTTPS), un tiek izpildīts attālās procedūras izsaukums (Remote Procedure Call - RPC), un aploksne tiek atgriezta kopā ar informāciju XML formatētā dokumentā.

Svarīgi ir tas, ka viena no SOAP priekšrocībām ir "vispārējā" transporta izmantošana, bet REST izmanto HTTP/HTTPS. SOAP pieprasījuma nosūtīšanai var izmantot gandrīz jebkuru transportu, bet REST - ne. Tātad šeit ir SOAP izmantošanas priekšrocība.

Kā jau minēju iepriekšējā rindkopā, "REST izmanto HTTP/HTTPS ", tāpēc nedaudz iedziļinieties šajos vārdos.

Kad mēs runājam par REST, izmantojot HTTP, visi HTTP piemērotie drošības pasākumi tiek pārņemti, un tas ir pazīstams kā transporta līmeņa drošība, un tas nodrošina ziņojumus tikai tad, kad tie ir iekšpusē, bet, kad jūs piegādājat tos otrā pusē, jūs nezināt, cik posmiem tiem būs jāiziet cauri, pirms tie sasniegs īsto punktu, kur dati tiks apstrādāti. Un, protams, visos šajos posmos var izmantot kaut ko citu, nevis HTTP.**Tātad Rest nav pilnīgi drošāks, vai ne?

Bet SOAP atbalsta SSL tāpat kā REST, turklāt atbalsta arī WS-Security, kas papildina dažas uzņēmumu drošības funkcijas. WS-Security nodrošina aizsardzību no ziņojuma izveides līdz pat tā patēriņam. Tātad transporta līmeņa drošībai jebkuras atrastās nepilnības var novērst, izmantojot WS-Security.

Papildus tam, tā kā REST ir ierobežots ar HTTP protokolu, tā kā tā darījumu atbalsts neatbilst ACID un nevar nodrošināt divfāžu apstiprinājumu sadalītiem starptautiskiem resursiem.

Bet SOAP ir visaptverošs atbalsts gan uz ACID balstītai darījumu pārvaldībai īstermiņa darījumiem, gan uz kompensāciju balstītai darījumu pārvaldībai ilgstošiem darījumiem. Tas atbalsta arī divu fāžu apstiprināšanu sadalītiem resursiem.

Es neizdaru nekādus secinājumus, bet es dodu priekšroku uz SOAP balstītiem tīmekļa pakalpojumiem, kamēr drošība, darījumi utt. ir galvenās problēmas.

Šeit ir "The Java EE 6 Tutorial", kur ir teikts RESTful dizains var būt piemērots, ja ir izpildīti šādi nosacījumi. Aplūkojiet.

*Domāju, ka jums patika lasīt manu atbildi.