Webservices – What is this SOAP or REST?
Simple Object Access Protocol (SOAP) and Representational State Transfer (REST) are two different, but similar, ways of talking to Web services out there in Internet Land.
There are two major types of web services:
What is SOAP?
SOAP is the long established and much used standard for webservices. It communicates using XML and was originally designed by Microsoft. If in doubt, SOAP is an easy place to start when looking at webservices, but bear in mind that older does not necessarily mean better.
Simply put, SOAP uses XML and a WSDL specification to handle it’s conversations. When Microsoft originally created the SOAP protocol it was to replace older technologies that didn’t understand the Internet — things like Distributed Component Object Model (DCOM) and Common Object Request Broker Architecture (CORBA). Older technologies use binary messaging to talk to each other but building a layer between applications talking with XML messaging lets different systems easily communicate over the internet.
There are some important differences between SOAP and REST
|SOAP is a protocol.||REST is an architectural style.|
|SOAP can’t use REST because it is a protocol.||REST can use SOAP web services because it is a concept and can use any protocol like HTTP, SOAP.|
|SOAP only permits XML.||REST permits many different data formats including plain text, HTML, XML, and JSON…|
|SOAP requires more bandwidth and more resources.||REST requires less bandwidth and less resources.|
|SOAP supports both SMTP and HTTP protocols.||REST requires the use of HTTP only.|
|SOAP is more reliable than REST.||REST is less secure than SOAP.|
|In most cases, SOAP is faster than REST.||REST is slower than SOAP.|
|SOAP defines its own security.||RESTful web services inherit security measures from the underlying transport.|
What is REST?
REST is the new kid on the block. REST was created to improve on areas that SOAP is a little “clunky”. I like REST because it has some cool features that SOAP doesnt offer (like JSON, CSV interfaces for example) but I’ve also found that SOAP can be easier to use because it doesnt have these options. Saying that, REST is quicker to code with because it doesnt have all the large cumbersome requirements of building long XML strings of data. REST communications are shorter and easier to code than SOAP (arguably).
REST provides a lighter weight alternative.
If SOAP is more verbose than REST – so why do I say it can be easier to use?
Because the wonderful IBM i Power System has a great integrated webserver (commonly referred to as the #IWS) which handles all the webservice XML & JSON conversions for us… but more on that later.
Should I use REST or SOAP?
Hmmm – the million dollar question.
SOAP is the established player in the world of Web service internet access.
- More verbose than REST but XML is easy for humans (aka programmers to read)
- Language, platform, and transport independent (REST requires use of HTTP)
- SOAP can be used in batch style environments because it uses XML format and not point-to-point
- The WSDL offers nice error handling and data validation before the XML data even gets to your webservice program
- XML is easy to use with RPG programs (a big bonus for us RPG ILE Programmers)
After saying all that – REST is easier to use because of it’s short form and it might require less programming work.
- REST has a smaller learning curve than SOAP (JSON is just as easy as XML really)
- It’s smaller so its faster (SOAP uses XML for messages, REST uses JSON which is a less-verbose message formats)
- a more modern standard that is growing rapidly
Personally – I would recommend start with REST and JSON. Get a feel for it. Play with the Integrated webservice and learn XML Play with SOAP and REST services and see which one floats your boat.