> So is SOAP.
No it's not. In theory, you can just consume the WSDL and have all the methods available to you, but in practice, there are huge and unbridgeable issues with interoperability. A C# SOAP client will have trouble consuming a Java WSDL, and so on.
> SOAP runs on just about anything including HTTP or even SMTP.
SOAP runs on top of HTTP but merely uses HTTP as a tunnel. All the stuff that should be in HTTP - the resource, the method, the data - is inside the XML envelope.
If you want to consume a SOAP web service, expect to get your hands dirty.
> SOAP doesn't care what the clients or servers are written in or run on.
In theory, no. In practice, interoperability is by no means a given.
> you can change something in a JSON packet and the client will only know it broke when it's run.
That's not really what I was talking about, but if you make a breaking API change in any system, you should have a way to do it so clients aren't caught flat-footed when their app breaks.
Neither REST nor SOAP inherently solves this problem, but REST does allow for custom media types that include versioning.