SOAP And REST

For my work report this semester, I decided to talk about RESTful web APIs and how they compare to SOAP based APIs. Conclusion: SOAP sucks. Here's a pretty interesting, fictional conversation that pretty much summarizes why SOAP is generally awful. Basically, SOAP rebuilds a lot of what's in HTTP from scratch. And to top it off, they use HTTP just as a transportation protocol, ignoring all the application level protocol stuff.

This is one of the biggest reasons why RESTful APIs are better than SOAP equivalents. For one, they use more than just HTTP PUT, so they get some free perks from HTTP (like cache-able GET calls). Because RESTful APIs are build as a thin layer over HTTP, you can even use your browser for testing. In practice, this has saved me loads of time. RESTful APIs also tend to actually use things like HTTP status codes, instead of reinventing error handling like SOAP does. SOAP just returns HTTP 200 (which indicates success  in HTTP world), but the response body might contain an error. What? Who thought that was a good idea?

In general, RESTful APIs are simpler (partially because they reuse parts of HTTP) than SOAP. They don't have to have every aspect XML-encoded, and there's no need to for something like WSDL (which, I should mention, is a clusterfuck).

So when you have a choice, always go with RESTful APIs. There are occasionally times where you might need to use SOAP (like when you need something like WS-Security), but for almost all applications, RESTful APIs are a much smarter choice.

So here's the 200-word version of my 2000-word work report (and I got to use the work "clusterfuck"!). :)