I have read articles about the differences between SOAP and REST as a web service communication protocol, but I think that the biggest advantages for REST over SOAP are:
REST is more dynamic, no need to create and update UDDI(Universal Description, Discovery, and Integration).
REST is not restricted to only XML format. RESTful web services can send plain text/JSON/XML.
But SOAP is more standardized (E.g.: security).
So, am I correct in these points?
SOAP and REST can't be compared directly, since the first is a protocol (or at least tries to be) and the second is an architectural style. This is probably one of the sources of confusion around it, since people tend to call REST any HTTP API that isn't SOAP.
Pushing things a little and trying to establish a comparison, the main difference between SOAP and REST is the degree of coupling between client and server implementations. A SOAP client works like a custom desktop application, tightly coupled to the server. There's a rigid contract between client and server, and everything is expected to break if either side changes anything. You need constant updates following any change, but it's easier to ascertain if the contract is being followed.
I think these are the crucial points to understand what REST is about, and how it differs from SOAP
SOAP (Simple Object Access Protocol) and REST (Representational State Transfer) are both ways to pass messages between computing processes over the Internet.
SOAP, which has been around for much longer, uses an XML payload to pass the messages. That XML payload can be delivered over the web (HTTP), but it can also be delivered via different protocols, such as those for email (SMTP).
So, think about it like a package you're sending to your buddy. They need to act on the instructions in your package. With SOAP, you have to construct those instructions in a rigid, detailed manner as an XML file and put it in a box and send it to your buddy. He then has to open the box, decipher those instructions, and act on them.
REST is much lighter weight. With REST, the messages are usually encoded as part of the URL, so a payload isn't absolutely necessary (though possible, of course). So a lot can be done with the usual HTTP methods of GET, POST, PUT, and DELETE. You can only use HTTP, though.
Think of REST this way: instead of having to create a bunch of instructions and package them up in a box, you just include the instructions as another line in the address (the URL) on the outside of the box itself. When you send that to your buddy, it's less work for them because they don't have to deal with opening the box, figuring out what's inside, and deciphering all those instructions.
That's way oversimplifying, but it's a start.