What are the main differences between these types of Web Services? In which cases do they apply? Is there any performance differences?
SOAP is a message transfer protocol in XML format for use in distributed environments. The SOAP standard works as a kind of framework that allows cross-platform interoperability with custom messages.
Applying this pattern to Web Services, WSDL is generally used to describe the structure of SOAP messages and possible actions on an endpoint.
One of the biggest advantages of this is that many languages and tools can read and generate messages easily. Several programming languages allow the generation of domain objects, Stubs and Skeletons from the WSDL definition, allowing remote communication via RPC through calls to remote methods, including complex arguments, as if they were local calls.
The problem with this pattern is that it adds considerable overhead, both because it's in XML and because it adds a lot of meta-information tags. Also, serializing and deserializing messages can be time consuming.
REST is another communication protocol, based on the HTTP hypermedia protocol. However, it does not impose restrictions on the message format, only on the behavior of the components involved.
The biggest advantage of the REST protocol is its flexibility. The developer can choose the most suitable format for system messages according to his specific need. The most common formats are JSON, XML and plain text, but in theory any format can be used.
This brings us to another advantage: Web Services that use REST are almost always "lighter" and therefore faster.
The problem with REST can arise precisely because of its advantages. As the definition of the data body is entirely up to the developer, interoperability issues are more common.
SOAP or REST?
Disclaimer: This is a pragmatic opinion.
In general, SOAP is a good choice for institutions with strict standards and complex environments (multiple platforms and systems). Many enterprise tools (such as ESB) take advantage of the standard and make it possible to filter, queue, sort, and redirect messages exchanged between systems.
For the rest, for day-to-day use, I don't see any concrete reasons not to use REST and JSON. Virtually every modern platform and language I know supports these concepts and the final solution is much simpler than the SOAP equivalent.
Furthermore, integrations with high volume of requests are not feasible in SOAP. REST is able to handle volume and complexity without difficulty, requiring only a minimum of developer experience to establish and enforce the proper standards.