Ik heb artikelen gelezen over de verschillen tussen SOAP en REST als een web service communicatieprotocol, maar ik denk dat de grootste voordelen voor REST boven SOAP zijn:
Maar SOAP is meer gestandaardiseerd (b.v.: beveiliging).
Dus, heb ik gelijk in deze punten?
Helaas zijn er veel misinformatie en misvattingen rond REST. Niet alleen jouw vraag en het antwoord van @cmd weerspiegelen die, maar het merendeel van de vragen en antwoorden over dit onderwerp op Stack Overflow. SOAP en REST kunnen niet direct met elkaar worden vergeleken, omdat het eerste een protocol is (of dat tenminste probeert te zijn) en het tweede een architectuurstijl is. Dit is waarschijnlijk een van de bronnen van verwarring eromheen, aangezien mensen de neiging hebben om REST elke HTTP API te noemen die niet SOAP'is. Om de dingen een beetje op te drijven en te proberen een vergelijking te maken, is het belangrijkste verschil tussen SOAP en REST de mate van koppeling tussen client en server implementaties. Een SOAP client werkt als een aangepaste desktop applicatie, strak gekoppeld aan de server. Er is een rigide contract tussen client en server, en er wordt verwacht dat alles kapot gaat als een van beide zijden iets verandert. Je hebt constante updates nodig na elke verandering, maar het'is gemakkelijker om na te gaan of het contract wordt gevolgd. Een REST-client lijkt meer op een browser. Het is een generieke client die weet hoe hij een protocol en gestandaardiseerde methodes moet gebruiken, en een applicatie moet daarbinnen passen. Je schendt de protocolstandaarden niet door extra methoden te creëren, je maakt gebruik van de standaardmethoden en creëert de acties ermee op je mediatype. Als je het goed doet, is er minder koppeling en kunnen veranderingen beter worden opgevangen. Een client wordt verondersteld een REST service binnen te gaan met nul kennis van de API, behalve voor het entry point en het media type. In SOAP moet de client voorkennis hebben over alles wat hij zal gebruiken, of hij zal niet eens beginnen met de interactie. Bovendien kan een REST-client worden uitgebreid met code-on-demand die door de server zelf wordt geleverd, het klassieke voorbeeld is JavaScript-code die wordt gebruikt om de interactie met een andere service aan de client-zijde te sturen. Ik denk dat dit de cruciale punten zijn om te begrijpen wat REST inhoudt, en hoe het verschilt van SOAP:
stackoverflow.com/questions/<id>
moet nemen, id moet vervangen door de Question.id en dat in je browser moet plakken. Dat'is onzin, maar dat'is wat veel mensen denken dat REST is.
Dit laatste punt kan'niet genoeg benadrukt worden. Als uw klanten URI's bouwen van sjablonen in documentatie en geen links krijgen in de resource representaties, dan is dat's geen REST. Roy Fielding, de auteur van REST, maakte het duidelijk in deze blogpost: REST API's moeten hypertext-gedreven zijn.
Met het bovenstaande in gedachten, zul je'll beseffen dat, terwijl REST misschien niet beperkt tot XML, om het correct te doen met elk ander formaat dat je'll moet ontwerpen en standaardiseren een of ander formaat voor uw links. Hyperlinks zijn standaard in XML, maar niet in JSON. Er zijn ontwerpstandaarden voor JSON, zoals HAL.
Tenslotte, REST is'niet voor iedereen, en een bewijs daarvan is hoe de meeste mensen hun problemen heel goed oplossen met de HTTP APIs die ze abusievelijk REST noemen en nooit verder gaan dan dat. REST is soms moeilijk om te doen, vooral in het begin, maar het betaalt zich na verloop van tijd uit met eenvoudiger evolutie aan de serverkant, en client's veerkracht voor veranderingen. Als je iets snel en gemakkelijk gedaan moet krijgen, doe dan geen moeite om REST goed te krijgen. Het is waarschijnlijk niet wat je zoekt. Als je iets nodig hebt dat jaren of zelfs decennia online moet blijven, dan is REST iets voor jou.REST
vs SOAP
is niet de juiste vraag om te stellen.
REST
, in tegenstelling tot SOAP
is niet een protocol.
REST
is een architectonische stijl en een ontwerp voor netwerk-gebaseerde software architecturen.
REST
concepten worden resources genoemd. Een representatie van een resource moet stateless zijn. Het wordt gerepresenteerd via een media type. Enkele voorbeelden van mediatypes zijn XML
, JSON
, en RDF
. Resources worden gemanipuleerd door componenten. Componenten vragen resources aan en manipuleren ze via een standaard uniforme interface. In het geval van HTTP, bestaat deze interface uit standaard HTTP ops zoals GET
, PUT
, POST
, DELETE
.
@Abdulaziz's vraag belicht wel het feit dat REST
en HTTP
vaak in tandem worden gebruikt. Dit is vooral te danken aan de eenvoud van HTTP en de zeer natuurlijke mapping naar RESTful principes.
Client-Server Communicatie
Client-server architecturen hebben een zeer duidelijke scheiding van belangen. Alle toepassingen gebouwd in de RESTful stijl moeten in principe ook client-server zijn.
Stateless
Elk clientverzoek aan de server vereist dat zijn toestand volledig wordt gerepresenteerd. De server moet in staat zijn om de clientaanvraag volledig te begrijpen zonder gebruik te maken van enige servercontext of server-sessiestatus. Hieruit volgt dat alle status op de client moet worden bijgehouden.
*Cacheable**
Cache constraints mogen worden gebruikt, zodat responsgegevens kunnen worden gemarkeerd als "cacheable" of "not-cacheable". Alle gegevens die als "cacheable" zijn gemarkeerd, mogen opnieuw worden gebruikt als antwoord op hetzelfde volgende verzoek.
Uniforme interface
De interactie tussen alle componenten moet verlopen via één enkele uniforme interface. Omdat alle interactie tussen componenten via deze interface verloopt, is interactie met verschillende diensten zeer eenvoudig. De interface is dezelfde! Dit betekent ook dat implementatiewijzigingen geïsoleerd kunnen worden doorgevoerd. Dergelijke veranderingen zullen geen invloed hebben op de fundamentele component interactie omdat de uniforme interface altijd ongewijzigd blijft. Een nadeel is dat je vastzit aan de interface. Als een optimalisatie zou kunnen worden aangebracht aan een specifieke service door de interface te veranderen, dan heb je pech, want REST verbiedt dit. Aan de andere kant is REST wel geoptimaliseerd voor het web, vandaar de ongelofelijke populariteit van REST over HTTP!
De bovenstaande concepten zijn de definiërende kenmerken van REST en onderscheiden de REST architectuur van andere architecturen zoals web services. Het is nuttig op te merken dat een REST service een web service is, maar dat een web service niet noodzakelijk een REST service is.
Zie deze blog post over REST Design Principles voor meer details over REST en de hierboven genoemde bullets.
EDIT: inhoud bijwerken op basis van opmerkingen
SOAP (Simple Object Access Protocol) en REST (Representation State Transfer) zijn allebei mooi op hun manier. Dus ik ga ze niet vergelijken. In plaats daarvan probeer ik het beeld te schetsen, wanneer ik er de voorkeur aan geef REST te gebruiken en wanneer SOAP.
Wat is payload?
Wanneer gegevens over het Internet worden verzonden, bevat elke verzonden eenheid zowel header-informatie als de eigenlijke gegevens die worden verzonden. De header identificeert de bron en de bestemming van het pakket, terwijl de eigenlijke gegevens worden aangeduid als de payload. In het algemeen is de payload de gegevens die namens een toepassing worden vervoerd en de gegevens die door het systeem van bestemming worden ontvangen.
Nu, bijvoorbeeld, ik moet een telegram versturen en we weten allemaal dat de kostprijs van het telegram afhangt van een aantal woorden.
Vertel me dus onder deze twee berichten, welke is goedkoper te verzenden?
<name>Arin</name>
of
"name": "Arin"
Ik weet dat uw antwoord de tweede zal zijn, hoewel beide dezelfde boodschap vertegenwoordigen is de tweede goedkoper qua kosten.
Dus ik probeer te zeggen dat, het verzenden van gegevens over het netwerk in JSON-formaat is goedkoper dan het verzenden in XML-formaat met betrekking tot de payload.
Dit is het eerste voordeel van REST ten opzichte van SOAP. SOAP ondersteunt alleen XML, maar REST ondersteunt verschillende formaten zoals tekst, JSON, XML, enz. En we weten al, als we Json gebruiken dan zijn we zeker op de betere plaats wat betreft de payload.
SOAP ondersteunt alleen XML, maar heeft ook zijn voordelen.**
**Echt waar! Hoe?
SOAP is op drie manieren op XML gebaseerd Envelope - die bepaalt wat er in het bericht staat en hoe het verwerkt moet worden.
Een set coderingsregels voor gegevenstypen, en tenslotte de opmaak van de procedure-aanroepen en de verzamelde antwoorden.
Deze enveloppe wordt via een transport (HTTP/HTTPS) verstuurd, en een RPC (Remote Procedure Call) wordt uitgevoerd, en de enveloppe wordt teruggestuurd met informatie in een XML geformatteerd document.
Het belangrijke punt is dat een van de voordelen van SOAP het gebruik van het "generieke" transport is, maar REST gebruikt HTTP/HTTPS. SOAP kan bijna elk transport gebruiken om het verzoek te verzenden, maar REST kan dat niet. Dus hier hebben we een voordeel van het gebruik van SOAP.
Zoals ik in bovenstaande paragraaf al heb gezegd "REST gebruikt HTTP/HTTPS ", dus ga wat dieper in op deze woorden.
Als we het hebben over REST over HTTP, dan worden alle beveiligingsmaatregelen die HTTP toepast overgenomen, en dit staat bekend als transport level security en het beveiligt berichten alleen terwijl het binnen de draad is maar zodra je het aan de andere kant aflevert weet je niet hoeveel stadia het zal moeten doorlopen voordat het het echte punt bereikt waar de gegevens zullen worden verwerkt. En natuurlijk kunnen al die stappen iets anders gebruiken dan HTTP. Dus Rest is niet helemaal veiliger, toch?
Maar SOAP ondersteunt SSL net als REST en daarbovenop ondersteunt het ook WS-Security wat een aantal enterprise security features toevoegt. WS-Security biedt bescherming vanaf de creatie van het bericht tot de consumptie ervan**. Dus voor beveiliging op transportniveau kan elke maas in de wet die we hebben gevonden, worden voorkomen met WS-Security.
Afgezien daarvan is REST beperkt door zijn HTTP-protocol, zodat de transactieondersteuning noch ACID-compliant is, noch een tweefasige commit over gedistribueerde transnationale bronnen kan bieden.
Maar SOAP heeft uitgebreide ondersteuning voor zowel ACID-gebaseerd transactiebeheer voor kortstondige transacties als compensatiegebaseerd transactiebeheer voor langlopende transacties. Het ondersteunt ook twee-fasen commit over gedistribueerde bronnen.
Ik trek geen conclusie, maar ik zal de voorkeur geven aan een op SOAP gebaseerde webdienst zolang veiligheid, transacties, enz. de belangrijkste punten van zorg zijn.
Hier is de "The Java EE 6 Tutorial" waar ze hebben gezegd Een RESTful ontwerp kan geschikt zijn als aan de volgende voorwaarden is voldaan. Kijk maar eens.
Hoop dat je mijn antwoord met plezier hebt gelezen.