Jeg har læst artikler om forskellene mellem SOAP og REST som kommunikationsprotokol for webtjenester, men jeg mener, at de største fordele ved REST i forhold til SOAP er:
REST er mere dynamisk, der er ikke behov for at oprette og opdatere UDDI (Universal Description, Discovery, and Integration).
REST er ikke begrænset til kun XML-format. RESTful webtjenester kan sende almindelig tekst/JSON/XML.
Men SOAP er mere standardiseret (f.eks.: sikkerhed).
Har jeg ret med hensyn til disse punkter?
Desværre er der en masse misinformation og misforståelser omkring REST. Ikke kun dit spørgsmål og svar fra @cmd afspejler disse, men de fleste spørgsmål og svar relateret til emnet på Stack Overflow. SOAP og REST kan ikke sammenlignes direkte, da den første er en protokol (eller i det mindste forsøger at være det), og den anden er en arkitektonisk stil. Dette er sandsynligvis en af kilderne til forvirring omkring det, da folk har en tendens til at kalde REST enhver HTTP API, der ikke er SOAP. Hvis man skubber lidt til tingene og forsøger at lave en sammenligning, er den største forskel mellem SOAP og REST graden af kobling mellem klient- og serverimplementationer. En SOAP-klient fungerer som et brugerdefineret desktop-program, der er tæt koblet til serveren. Der er en rigid kontrakt mellem klient og server, og det forventes, at alting går i stykker, hvis en af siderne ændrer noget. Det er nødvendigt med konstante opdateringer efter enhver ændring, men det er lettere at konstatere, om kontrakten overholdes. En REST-klient er mere som en browser. Det er en generisk klient, der ved, hvordan man bruger en protokol og standardiserede metoder, og en applikation skal passe ind i den. Man overtræder ikke protokolstandarderne ved at skabe ekstra metoder, man udnytter standardmetoderne og skaber handlinger med dem på sin medietype. Hvis det gøres rigtigt, er der mindre kobling, og ændringer kan håndteres mere elegant. Det er meningen, at en klient skal gå ind i en REST-tjeneste uden kendskab til API'et, bortset fra indgangspunktet og medietypen. I SOAP skal klienten have forudgående viden om alt det, den skal bruge, ellers vil den ikke engang begynde interaktionen. Desuden kan en REST-klient udvides med kode på forespørgsel fra serveren selv, idet det klassiske eksempel er JavaScript-kode, der bruges til at styre interaktionen med en anden tjeneste på klientsiden. Jeg mener, at dette er de afgørende punkter for at forstå, hvad REST handler om, og hvordan det adskiller sig fra SOAP:
stackoverflow.com/questions/<id>
, erstatte id med Question.id og indsætte den i din browser. Det er noget vrøvl, men det er det, som mange mennesker tror, at REST er.
Dette sidste punkt kan ikke understreges nok. Hvis dine klienter opbygger URI'er fra skabeloner i dokumentationen og ikke får links i ressourcerepræsentationerne, er det ikke REST. Roy Fielding, forfatteren af REST, gjorde det klart i dette blogindlæg: REST API'er skal være hypertekstdrevne.
Med ovenstående i tankerne vil du indse, at selv om REST måske ikke er begrænset til XML, skal du designe og standardisere et format til dine links for at gøre det korrekt med ethvert andet format. Hyperlinks er standard i XML, men ikke i JSON. Der findes udkast til standarder for JSON, f.eks. HAL.
Endelig er REST ikke for alle, og et bevis på det er, hvordan de fleste mennesker løser deres problemer meget godt med de HTTP-API'er, som de fejlagtigt kalder REST, og aldrig vover sig videre end det. REST er svært at lave nogle gange, især i begyndelsen, men det betaler sig med tiden med nemmere udvikling på serversiden og klienternes modstandsdygtighed over for ændringer. Hvis du har brug for noget, der skal gøres hurtigt og nemt, skal du ikke bekymre dig om at få REST rigtigt. Det er sandsynligvis ikke det, du leder efter. Hvis du har brug for noget, der skal forblive online i årevis eller endda årtier, er REST noget for dig.REST
vs SOAP
er ikke det rigtige spørgsmål at stille.
REST
er i modsætning til SOAP
ikke en protokol.
REST
er en arkitektonisk stil og et design for netværksbaserede softwarearkitekturer.
REST
-koncepter betegnes som ressourcer. En repræsentation af en ressource skal være stateless. Den repræsenteres via en eller anden medietype. Nogle eksempler på medietyper omfatter XML
, JSON
og RDF
. Ressourcer manipuleres af komponenter. Komponenter anmoder om og manipulerer ressourcer via en ensartet standardgrænseflade. I HTTP-sagen består denne grænseflade af standard-HTTP-operationer, f.eks. GET
, PUT
, POST
og DELETE
.
@Abdulaziz's spørgsmål belyser det faktum, at REST
og HTTP
ofte anvendes sammen. Dette skyldes primært HTTP's enkelhed og dets meget naturlige afbildning af RESTful-principperne.
Klient-server-kommunikation
Klient-server-arkitekturer har en meget tydelig adskillelse af problemer. Alle applikationer, der er bygget i RESTful-stil, skal i princippet også være klient-server-applikationer.
Stateless
Hver klientforespørgsel til serveren kræver, at dens tilstand er fuldt repræsenteret. Serveren skal være i stand til at forstå klientens anmodning fuldt ud uden at bruge nogen serverkontekst eller server-sessionstilstand. Det følger heraf, at al tilstand skal opbevares på klienten.
Cacheable
Der kan anvendes cachebegrænsninger, således at svardata kan markeres som cachelagbare eller ikke-cachelagbare. Alle data, der er markeret som cacheable, kan genbruges som svar på den samme efterfølgende anmodning.
Uniform Interface
Alle komponenter skal interagere gennem en enkelt ensartet grænseflade. Da al komponentinteraktion foregår via denne grænseflade, er interaktion med forskellige tjenester meget enkel. Grænsefladen er den samme! Det betyder også, at implementeringsændringer kan foretages isoleret. Sådanne ændringer vil ikke påvirke den grundlæggende komponentinteraktion, fordi den ensartede grænseflade altid er uændret. En ulempe er, at man sidder fast med grænsefladen. Hvis en optimering kunne gives til en bestemt tjeneste ved at ændre grænsefladen, er du ude af held, da REST forbyder dette. På den lyse side er REST imidlertid optimeret til internettet, hvilket er grunden til den utrolige popularitet af REST over HTTP!
Ovenstående begreber er definerende kendetegn for REST og adskiller REST-arkitekturen fra andre arkitekturer som f.eks. webtjenester. Det er nyttigt at bemærke, at en REST-tjeneste er en webtjeneste, men at en webtjeneste ikke nødvendigvis er en REST-tjeneste.
Se dette blog indlæg om REST-designprincipper for at få flere oplysninger om REST og de ovennævnte punkter.
EDIT: opdaterer indhold på baggrund af kommentarer
SOAP (Simple Object Access Protocol) og REST (Representation State Transfer) er begge smukke på hver deres måde. Så jeg sammenligner dem ikke. I stedet forsøger jeg at skildre billedet, hvornår jeg foretrak at bruge REST og hvornår SOAP.
Hvad er payload?
Når data sendes over internettet, indeholder hver enhed, der sendes, både headerinformationer og de faktiske data, der sendes. Headerne identificerer pakkens kilde og destination, mens de faktiske data kaldes payload. Generelt er nyttelasten de data, der transporteres på vegne af et program, og de data, der modtages af destinationssystemet.
Nu skal jeg f.eks. sende et Telegram, og vi ved alle, at telegrammets omkostninger vil afhænge af nogle ord.
Så fortæl mig, hvilken af de to beskeder, der er nævnt nedenfor, er billigst at sende?
<name>Arin</name>
eller
"name": "Arin"
Jeg ved, at dit svar vil være det andet, selv om begge repræsenterer det samme budskab, er det andet billigere med hensyn til omkostninger.
Så jeg forsøger at sige, at det er billigere at sende data over nettet i JSON-format end at sende dem i XML-format med hensyn til nyttelast.
Her er den første fordel eller fordelene ved REST i forhold til SOAP. SOAP understøtter kun XML, men REST understøtter forskellige formater som tekst, JSON, XML osv. Og vi ved allerede, at hvis vi bruger Json, vil vi helt sikkert være bedre stillet med hensyn til nyttelast.
SOAP understøtter kun XML, men det har også sine fordele.
Helt ærligt! Hvordan?
SOAP er afhængig af XML på tre måder Envelope - der definerer, hvad der er i meddelelsen, og hvordan den skal behandles.
Et sæt kodningsregler for datatyper og endelig layoutet af procedureopkald og de indsamlede svar.
Denne konvolut sendes via en transport (HTTP/HTTPS), og der udføres et RPC (Remote Procedure Call), og konvolutten returneres med oplysninger i et XML-formateret dokument.
Det vigtige punkt er, at en af fordelene ved SOAP er brugen af den "generiske" transport, men REST bruger HTTP/HTTPS. SOAP kan bruge næsten enhver transport til at sende anmodningen, men det kan REST ikke. Så her har vi en fordel ved at bruge SOAP.
Som jeg allerede har nævnt i ovenstående afsnit "REST bruger HTTP/HTTPS ", så gå lidt dybere ind i disse ord.
Når vi taler om REST over HTTP, overtages alle de sikkerhedsforanstaltninger, der anvendes i HTTP, og dette er kendt som transport level security, og det sikrer kun meddelelser, mens den er inde i ledningen, men når du har leveret den på den anden side, ved du ikke, hvor mange trin den skal igennem, før den når frem til det rigtige punkt, hvor dataene vil blive behandlet. Og selvfølgelig kan alle disse trin bruge noget andet end HTTP.Så Rest er ikke helt sikker, vel?
Men SOAP understøtter SSL ligesom REST og understøtter desuden også WS-Security, som tilføjer nogle virksomhedssikkerhedsfunktioner. WS-Security giver beskyttelse fra oprettelsen af meddelelsen til dens forbrug. Så hvad end vi finder et sikkerhedshul på transportniveau, kan det forhindres ved hjælp af WS-Security.
Bortset fra det er REST begrænset af sin HTTP-protokol, så dens transaktionsunderstøttelse er hverken ACID-kompatibel eller kan give tofaset commit på tværs af distribuerede transnationale ressourcer.
Men SOAP har omfattende støtte til både ACID-baseret transaktionsstyring for kortvarige transaktioner og kompensationsbaseret transaktionsstyring for langvarige transaktioner. Den understøtter også to-fase commit på tværs af distribuerede ressourcer.
Jeg drager ikke nogen konklusion, men jeg vil foretrække SOAP-baserede webtjenester, mens sikkerhed, transaktioner osv. er de vigtigste bekymringer.
Her er "The Java EE 6 Tutorial" hvor de har sagt A RESTful design may be appropriate when the following conditions are met. Tag et kig.
Håber du nød at læse mit svar.