When I talk about the advantages of using the REST API, I usually talk about REST-based web services and compare this to SOAP-based web services. And there are a lot of advantages to using the REST API: there’s no need to define a web service since it’s always there, the interaction with the interface is a lot easier since the requests are a lot smaller, but most of all it’s intuitive. I often find that SOAP is a complex mechanism which can be challenging to use.


But that’s only a problem if you’re planning to handle the communication yourself. Say, you’re building an application in Java or need to get data to a different system that runs on PHP, in that case the REST-based web service is the obvious choice since all you’re doing is sending and receiving simple HTTP requests and responses.


ws soap.pngSo is there any need for SOAP at all? I’d argue there is. A SOAP-based web service uses the WSDL to describe in detail how everything works. That includes how the request should be formatted, what operations are on offer and what the response should look like. This means you know everything prior to starting your request. These are usually considered added complexities, but if you use an application that handles all of this for you, this doesn’t really matter that much. Because that’s where I see the added value of SOAP-based web services: if you use an application that can deal with the information in the WSDL and interpret it for you it’s actually easy to use.


Doing the same thing with REST-based clients is a lot trickier. A REST client acts a like a generic client and enters a REST service with little knowledge of the API, except for the entry point. An application might find it difficult to predict all those details that SOAP would store in the WSDL.


One such client is Remedy. When we consume a web service, we act as a SOAP client. During the design phase we read the WSDL file and allow the developer to simply map the fields to the XML elements. The system takes it from there. You don’t have to be concerned with creating SOAP requests, reading the WSDL file, etc.


I think SOAP-based web services work particularly well in a setting where the application can easily interpret the web service. If you have that available and there’s no need to do any coding, SOAP is probably a better choice. To learn more, attend my session, Session 233: Getting the Most out of Your Web Services Integration, at BMC Engage where we’ll be looking at SOAP-based services and REST-based web services.


Hope to see you there,




Don't forget to follow me on Twitter!