Olen lukenut artikkeleita SOAPin ja RESTin eroista verkkopalvelun viestintäprotokollana, mutta mielestäni RESTin suurimmat edut SOAPiin verrattuna ovat seuraavat:
REST on dynaamisempi, eikä UDDI:tä (Universal Description, Discovery, and Integration) tarvitse luoda ja päivittää.
REST ei rajoitu vain XML-muotoon. RESTful-verkkopalvelut voivat lähettää tavallista tekstiä/JSON/XML.
Mutta SOAP on standardisoitu enemmän (esim. turvallisuus).
Olenko siis oikeassa näissä kohdissa?
Valitettavasti RESTiin liittyy paljon väärää tietoa ja väärinkäsityksiä. Niitä eivät heijasta ainoastaan kysymyksesi ja @cmd:n vastaus, vaan myös suurin osa Stack Overflow'n aiheeseen liittyvistä kysymyksistä ja vastauksista. SOAPia ja RESTiä ei voi suoraan verrata toisiinsa, koska ensimmäinen on protokolla (tai ainakin yrittää olla) ja toinen on arkkitehtuurityyli. Tämä on luultavasti yksi sekaannuksen syistä, sillä ihmiset kutsuvat RESTiksi mitä tahansa HTTP-API:tä, joka ei ole SOAP. Jos yritämme hieman ponnistaa ja vertailla asioita, SOAPin ja RESTin tärkein ero on asiakkaan ja palvelimen toteutusten välisen kytkennän aste. SOAP-asiakas toimii kuin mukautettu työpöytäsovellus, joka on tiukasti kytketty palvelimeen. Asiakkaan ja palvelimen välillä on jäykkä sopimus, ja kaiken odotetaan rikkoutuvan, jos jompikumpi osapuoli muuttaa jotain. Kaikkien muutosten jälkeen tarvitaan jatkuvia päivityksiä, mutta on helpompi varmistaa, että sopimusta noudatetaan. REST-asiakas on enemmän kuin selain. Se on yleinen asiakasohjelma, joka osaa käyttää protokollaa ja standardoituja menetelmiä, ja sovelluksen on mahduttava sen sisään. Protokollastandardeja ei rikota luomalla ylimääräisiä metodeja, vaan hyödynnetään standardimetodeja ja luodaan niiden avulla toimia mediatyypissä. Jos se tehdään oikein, kytkeytyminen on vähäisempää, ja muutokset voidaan käsitellä helpommin. Asiakkaan on tarkoitus tulla REST-palveluun tietämättä API:sta mitään muuta kuin sisäänmenopisteen ja mediatyypin. SOAP-palvelussa asiakkaan on tiedettävä etukäteen kaikki käyttämänsä asiat, tai se ei edes aloita vuorovaikutusta. Lisäksi REST-asiakasta voidaan laajentaa palvelimen itsensä toimittamalla koodilla, jonka klassisena esimerkkinä on JavaScript-koodi, jota käytetään vuorovaikutuksen ohjaamiseen toisen palvelun kanssa asiakaspuolella. Mielestäni nämä ovat ratkaisevia kohtia, joiden avulla voi ymmärtää, mistä REST:ssä on kyse ja miten se eroaa SOAP:sta:
stackoverflow.com/questions/<id>
, korvattava id kysymyksen id:llä ja lisättävä se selaimeesi. Tämä on hölynpölyä, mutta monet luulevat, että REST on juuri sitä.
Tätä viimeistä kohtaa ei voi korostaa tarpeeksi. Jos asiakkaasi luovat URI:t dokumentaation malleista eivätkä saa linkkejä resurssien esityksiin, se ei ole REST. Roy Fielding, RESTin kirjoittaja, teki asian selväksi tässä blogikirjoituksessa: REST-API:iden on oltava hypertekstipohjaisia.
Edellä esitetyn perusteella ymmärrät, että vaikka REST ei välttämättä rajoitu XML:ään, sinun on suunniteltava ja standardoitava jokin linkkien muoto, jos haluat tehdä sen oikein minkä tahansa muun formaatin kanssa. Hyperlinkit ovat standardoitu XML:ssä, mutta eivät JSON:ssa. JSON:lle on olemassa standardiluonnoksia, kuten HAL.
Lopuksi, REST ei sovi kaikille, ja todisteena tästä on se, että useimmat ihmiset ratkaisevat ongelmansa hyvin HTTP-rajapinnoilla, joita he kutsuvat virheellisesti RESTiksi, eivätkä koskaan uskaltaudu sitä pidemmälle. REST on joskus vaikea toteuttaa, varsinkin alussa, mutta se kannattaa ajan mittaan, kun palvelin kehittyy helpommin ja asiakas kestää muutoksia. Jos haluat tehdä jotain nopeasti ja helposti, älä vaivaudu REST:n oikeanlaiseen käyttöön. Se ei todennäköisesti ole sitä, mitä etsit. Jos tarvitset jotain, jonka on oltava verkossa vuosia tai jopa vuosikymmeniä, REST on sinua varten.REST
vs. SOAP
on ei oikea kysymys.
Toisin kuin "SOAP", "REST" on ei protokolla.
REST
on arkkitehtuurityyli ja suunnitelma verkkopohjaisia ohjelmistoarkkitehtuureja varten.
REST
-käsitteisiin viitataan resursseina. Resurssin esityksen on oltava tilaton. Se esitetään jonkin mediatyypin avulla. Esimerkkejä mediatyypeistä ovat XML
, JSON
ja RDF
. Resursseja käsitellään komponenteilla. Komponentit pyytävät ja käsittelevät resursseja standardoidun yhtenäisen rajapinnan kautta. HTTP:n tapauksessa tämä rajapinta koostuu tavanomaisista HTTP-operaatioista, kuten GET
, PUT
, POST
ja DELETE
.
@Abdulaziz'n kysymys valaisee sitä, että REST
ja HTTP
ovat usein käytössä yhdessä. Tämä johtuu ensisijaisesti HTTP:n yksinkertaisuudesta ja sen hyvin luonnollisesta yhdistämisestä RESTful-periaatteisiin.
Asiakas-palvelin-viestintä
Asiakas-palvelin -arkkitehtuurissa on hyvin selkeä huolenaiheiden erottelu. Kaikkien RESTful-tyyliin rakennettujen sovellusten on myös periaatteessa oltava asiakas-palvelin-sovelluksia.
Stateless
Jokainen palvelimelle osoitettu asiakaspyyntö edellyttää, että sen tila on täysin edustettuna. Palvelimen on pystyttävä ymmärtämään asiakkaan pyyntö täysin ilman palvelinkontekstin tai palvelimen istuntotilan käyttöä. Tästä seuraa, että kaikki tila on säilytettävä asiakkaalla.
Cacheable
Voidaan käyttää välimuistirajoituksia, jolloin vastaustiedot voidaan merkitä välimuistiin tallennettaviksi tai ei-välimuistiin tallennettaviksi. Kaikki välimuistiin tallennettavaksi merkitty tieto voidaan käyttää uudelleen vastauksena samaan seuraavaan pyyntöön.
Yhtenäinen rajapinta
Kaikkien komponenttien on oltava vuorovaikutuksessa yhden yhtenäisen rajapinnan kautta. Koska kaikki komponenttien välinen vuorovaikutus tapahtuu tämän rajapinnan kautta, vuorovaikutus eri palveluiden kanssa on hyvin yksinkertaista. Rajapinta on sama! Tämä tarkoittaa myös sitä, että toteutusmuutokset voidaan tehdä eristyksissä. Tällaiset muutokset eivät vaikuta komponenttien perustavanlaatuiseen vuorovaikutukseen, koska yhtenäinen rajapinta pysyy aina muuttumattomana. Yksi haittapuoli on se, että rajapinta on sidottu. Jos tiettyyn palveluun voitaisiin tarjota optimointia muuttamalla käyttöliittymää, sinua ei onnista, koska REST kieltää tämän. Positiivisena puolena on kuitenkin se, että REST on optimoitu verkkoa varten, mistä johtuu RESTin uskomaton suosio HTTP:n yli!
Edellä esitetyt käsitteet ovat REST-arkkitehtuurin ominaispiirteitä ja erottavat REST-arkkitehtuurin muista arkkitehtuureista, kuten verkkopalveluista. On hyödyllistä huomata, että REST-palvelu on verkkopalvelu, mutta verkkopalvelu ei välttämättä ole REST-palvelu.
Katso tästä blogikirjoituksesta post REST-suunnitteluperiaatteet lisätietoja RESTistä ja edellä mainituista kohdista.
EDIT: päivittää sisältöä kommenttien perusteella.
SOAP (Simple Object Access Protocol) ja REST (Representation State Transfer) ovat molemmat kauniita omalla tavallaan. En siis vertaile niitä keskenään. Sen sijaan yritän kuvata, milloin käytän mieluummin RESTiä ja milloin SOAPia.
Mikä on hyötykuorma?
Kun tietoja lähetetään Internetissä, jokainen lähetettävä yksikkö sisältää sekä otsikkotietoja että varsinaista lähetettävää dataa. Otsikko yksilöi paketin lähteen ja määränpään, kun taas varsinaista dataa kutsutaan hyötykuormaksi. Yleisesti ottaen hyötykuorma on sovelluksen puolesta kuljetettava data ja kohdejärjestelmän vastaanottama data.
Esimerkiksi minun on lähetettävä sanoma, ja me kaikki tiedämme, että sähkeen hinta riippuu joistakin sanoista.
Kertokaa siis, kumpi näistä kahdesta alla mainitusta viestistä on halvempi lähettää?
<name>Arin</name>
tai
"name": "Arin"
Tiedän, että vastauksesi on toinen, vaikka molemmat edustavat samaa viestiä toinen on halvempi kustannusten suhteen.
Yritän siis sanoa, että tiedon lähettäminen verkon kautta JSON-muodossa on hyötykuorman osalta halvempaa kuin sen lähettäminen XML-muodossa.
Tässä on RESTin ensimmäinen hyöty tai etu SOAPiin verrattuna. SOAP tukee vain XML:ää, mutta REST tukee eri muotoja, kuten tekstiä, JSON:ia, XML:ää jne. Ja tiedämme jo, että jos käytämme Jsonia, olemme varmasti paremmassa asemassa hyötykuorman suhteen.
SOAP tukee vain XML:ää, mutta myös sillä on etunsa..
Todellakin! Miten?
SOAP tukeutuu XML:ään kolmella tavalla Kirjekuori - siinä määritellään, mitä sanoma sisältää ja miten sitä käsitellään.
Tietotyyppien koodaussäännöt ja lopuksi menettelykutsujen ja kerättyjen vastausten ulkoasu.
Tämä kirjekuori lähetetään liikenteen (HTTP/HTTPS) kautta, ja RPC (Remote Procedure Call) suoritetaan, ja kirjekuori palautetaan XML-muotoisena asiakirjana.
Tärkeää on, että Yksi SOAPin eduista on "yleisen" liikenteen käyttö, mutta REST käyttää HTTP/HTTPS:ää. SOAP voi käyttää melkein mitä tahansa kuljetusmuotoa pyynnön lähettämiseen, mutta REST ei. Tässä on siis SOAPin käytön etu.
Kuten jo mainitsin edellä olevassa kohdassa "REST käyttää HTTP/HTTPS:ää ", joten tutustu hieman syvällisemmin näihin sanoihin.
Kun puhumme REST:stä HTTP:n välityksellä, kaikki HTTP:tä sovellettavat turvatoimet periytyvät, ja tämä tunnetaan nimellä transport level security, ja se turvaa viestit vain silloin, kun ne ovat johdon sisällä, mutta kun ne toimitetaan toiselle puolelle, et tiedä, kuinka monta vaihetta niiden on käytävä läpi, ennen kuin ne saavuttavat todellisen pisteen, jossa tiedot käsitellään. Ja tietysti kaikissa näissä vaiheissa voidaan käyttää jotain muuta kuin HTTP:tä. Ei siis Rest ole täysin turvallinen, eikö niin?.
Mutta SOAP tukee SSL:ää aivan kuten REST, ja lisäksi se tukee myös WS-Securityä, joka lisää joitakin yrityksen turvaominaisuuksia. WS-Security tarjoaa suojaa viestin luomisesta sen kuluttamiseen. Kuljetustason tietoturvan osalta kaikki löytämämme porsaanreiät voidaan siis estää WS-Securityn avulla.
Tämän lisäksi, koska REST on rajoitettu HTTP-protokollaan, sen transaktiotuki ei ole ACID-yhteensopiva eikä se voi tarjota kaksivaiheista sitoutumista hajautetuissa kansainvälisissä resursseissa.
SOAP tarjoaa kuitenkin kattavan tuen sekä ACID-pohjaiselle transaktiohallinnalle lyhytaikaisia transaktioita varten että korvauspohjaiselle transaktiohallinnalle pitkäkestoisia transaktioita varten. Se tukee myös kaksivaiheista sitoutumista hajautettujen resurssien välillä.
En tee mitään johtopäätöksiä, mutta suosin SOAP-pohjaista verkkopalvelua, kun tietoturva, transaktiot jne. ovat tärkeimpiä huolenaiheita.
Tässä on "The Java EE 6 Tutorial", jossa he ovat sanoneet RESTful-suunnittelu voi olla tarkoituksenmukaista, kun seuraavat ehdot täyttyvät. Katsokaa.
*Toivottavasti nautit vastaukseni lukemisesta.