Judging by the looks of current web platform APIs, like those of social networks, Amazon’s web services, photo sharing sites like Flickr or Instagram and many more, one could get the impression that REST has fully replaced the much maligned SOAP as the underlying communications architecture.
However, this is only true at first glance. Lots of company internal or B2B services are implemented with SOAP – especially where there is a need for more complex operations than in typical CRUD scenarios – or for more complex data structures and formal function signatures.
First things first though: This post is not about comparing advantages and disadvantages of REST and SOAP or a discussion of whether they should be compared at all – others have done that at great depth already.
Instead, this is about those cases where the decision for SOAP and against REST has already been made and where you now have to implement an iOS application that acts as a consumer of SOAP services.
The use of SOAP sometimes has historical reasons, because it might have already been established before REST became popular. But using it can also be a conscious decision, e. g. when a formally verifiable and very explicit specification is required for internal or external consumers.
Java: Which library would you like?
In the Java ecosystem you can choose from a range of web service libraries that have grown quite reliable over the years and can be plugged into most projects easily by ways of simply adding a few lines of XML to the pom.xml.
Classes generated based on the service’s WSDL take care of transparently encapsulating HTTP communication and the (un-)marshalling of data structures between XML and the Java representation. Thanks to static typing IDEs can offer code completion and other convenience features. With current versions of JAXB, JavaEE, Spring and others you can even stop worrying about (formerly required) mandatory dependency hierarchies, as annotations and dependency injection help getting rid of that plumbing. Just make sure to have the relevant JARs in your classpath at runtime, and off you go.
For Android and especially JavaME there is certainly less choice in frameworks, but there are solutions there, too.
On the other side…
RestKit provides an actively developed and widely used framework to use RESTful web services from iOS. However, regarding SOAP we’re not so lucky.
Searching Google for “ios soap client” produces quite a number of hits, however many of these are very narrowly focussed on specific individual problems or they present very simple (read: hardly usable) solutions, ranging from String-Concats and regular expressions to other quite rudimentary techniques.
Apart from that, you can find a few unfinished attempts at (not very well maintained) generic web service frameworks. Some of them (like wsdl2objc) are written in Objective-C themselves, others (like csoap or gsoap) are pure C libraries without objected oriented APIs. Artifacts generated by these tools sometimes require manual tweaking before they can be compiled against the iOS SDK and are therefore not ideally suited for quick application development.
The Apache 2.0 licensed sudzc on the other hand pursues a different approach. It provides a web interface for uploading or pointing at a WSDL service description and transforms it via server-side code written in ASP.NET/C# and a series of XSLT templates to iOS compatible artifacts, conveniently packaged as a full Xcode project in a ZIP.
Seasoned Java developers sometimes have a rough start with the (dynamic) Objective-C language and the initially alien development environment. They usually miss the undoubtedly excellent IDE support that Java enables through its static type system.
For a current customer project we decided on sudzc for our SOAP needs, because it produces artifacts that are very reminiscent of what you would expect when working with Java. This made it easy to focus on customer requirements and not have to delve in to technical details too much.