This article will demystify the enigma of SOAP or REST once for all. As a software developer I can remember the struggles which I have endured to u...
For further actions, you may consider blocking this person and/or reporting abuse
I think it's good to know where SOAP comes from in order to understand why it's so complicated. In the days when SOAP was born, there was no REST. And there were no SPAs. Frontend developers were not the people SOAP was made for. Instead it was made for backend developers. SOAP was made for asynchronous message communication between your enterprise services.
The good thing about SOAP is that it's a widely adopted standard for backend services. But it was made to be a solution for each and every problem, everything was put into the message, the service description (WSDL) contains a schema for validating the XML messages, and even security (WS Security) is part of SOAP (no, that's definitely not a "Pro" point, Ali)! Nowadays everybody knows that separating concerns is the way to go, and moving security into the transport layer (SSL) is one of the reasons why REST is so simple.
That's right , indeed the WS-Security is part of SOAP, but i have mentioned it as its Pros because of the flexibility and the fact that you can implement your custom security needs while in SSL you need to follow the protocol , but of course you need to consider the cost of the performance and bandwidth.
Good point though :) therefore i have edited the text
Thank you, Ali. At least they didn't make WS-Security mandatory in SOAP, so you're free to do security in the transport layer when using SOAP.
WS security is way more than TLS. It covers integrity, confidentiality (encryption) and identity verification, and does it in a protocol agnostic way. Second point can be achieved with HTTPS on protocols where available, the others are not covered by TLS. Also in some cases it is redundant to encrypt the full message, only parts need encryption and this reduces overhead. Ie internal services often communicate over http to not have the overhead of https but some parts of some messages may need encryption and WS security provides an off the shelve solution. Yes these come with a cost but so does TLS.
maybe it’s worth to mention RPC, and graphql to completely blows up reader’s mind ;)
Well, SOAP is RPC realisation. :) But yes, IMO it's better to compare SOAP and other RPC's (like JSON RPC or GRPC), than comparing it to REST.
I've always felt that SOAP should be mostly used for business communication, since you need some sort of contract done for each application consuming your endpoints, whenever REST covers anything else out of that scope.
Wow, there are people who still use SOAP I thought that everyone is moving towards REST.
Anyway, I do agree that it should be compared to other protocols like GRPC or GraphQL to be that extensive which API Evangelist has done a good job for it.
Love the way you've explained what a protocol is. I'm definitely going to pinch that!
Not sure if you are just trolling or you are just ignorant or what happened to you, but SOAP is the worst protocol ever and your counterpoints against REST are bogus.
This is my favorite stack overflow answer of all time.
stackoverflow.com/questions/209905...
soap = to get clean with, rest = to get json response data. Seriously, I would avoid soap at all costs if you can use rest instead