I was asked what are the disadvantages of using RESTful over SOAP, I couldn’t think of any - maybe having to access a legacy system? Any ideas?

Rest has little validation and implements only crud in most instances. It also features no clearly defined practice for things like querying and filtering. HATEOAS can be difficult to implement as well depending on the system so few people actually do it. REST paradigmatically fails to define a metadata convention.

SOAP is needlessly verbose in format and therefore somewhat slow and bandwidth intensive. It's rules, restrictions and validation metrics aren't understood by most people using it, the frameworks that support it tend to be obtuse and it has a lot of ceremony. SOAP also provides no canonical strategy for linking to an operational domain, so most people just dump a large pile of procedures and let the docs sort them out. WSDL is another obtuse grammar for an obtuse pseudo-arbitrary grammar.

Asking the strengths is a better question.

Awesome reply @SortOfTested thank you. Do what would you say are the strengths?

Rest generally uses less boiler plate around data and client systems can often easier implement data conversion. Often its json and arguments are mostly so easy you can hand craft valid calls.

Soap with the right tools to generate a client is actually very easy to consume.

You dump the endpoint url into a generator and get a class that handles all data conversion to and from your local datatypes.

@voxera something like this? https://soapui.org/docs/...

@feynman
REST tends to be more straightforward and easy to implement on the whole. Surrounding infrastructure in regards to things like OpenAPI fill a lot of its gaps (in much the same way SOAP did for XML-RPC). REST is also opinionated towards its protocol and flexible in terms of its message serialization strategies. APIs are discoverable and composable.

SOAP has a much higher mandated stringency in terms of its message contracts. It has robust validation facility and metadata as a facet of its construction. It's well established and predictable. SOAP gets the benefits inherent in RPC which, when done well, makes it easier for engineers to expose just an API that doesn't require their users to have exhaustive knowledge of a given domain and instead presents explicit, finite operations; this is counter to REST's approach to API composition.

Note: SOAP can use a message strategy other than XML, but it's originally designed to couple with XML-RPC.

I'll throw my PC out the window if i have to stare at a WSDL again.

@SortOfTested - thank you for the time you took for your excellent replies. You obviously have a good depth of understanding in this area, a clear and detailed overview. Thanks for sharing 🙂