Is wsdl2objc and similar SOAP client generators really the best choice for iOS and OS X?

Question

I do realize that this question seems very well known, but since I don't have a lot of experience using SOAP web services and as far as I could find this is not very common topic on iOS and especially OS X, I will ask it again.

I have tried wsdl2objc and sudzobjc and both solutions seem to be pretty much complex. I have a feeling that there is a lot of overhead, too, especially with all those types defined and pointers used.

If I compare this to simply using standard Cocoa classes NSURLConnection and NSXMLParser like in this example:

http://abhicodehelp.blogspot.com/2010/12/handling-soap-with-iphone.html

like when using RESTful web services, it feels like overkill...

I would appreciate anybody to give me a hint, why this more complete approach is better and wouldn't it be better to use any other C or C++ libraries that at least by first look seem much lighter and easier to use?

Answer 1

The problem of SOAP is that it's really, really bloated! It's called Simple Object Access Protocoll but it's anything but simple. It's based on XML and (mis)uses all of it's complexity with WSDL and XMLSchemes and all that stuff. I started working with SOAP in my Java time as it was just invented. And we had OutOfMemoryExceptions more than once because of the size of the XML message.

That said: calling SOAP services with Objective-C will be as complicated as it is with Java or any other language. The problem is you need to create rather (or even very) complex XML structures to call a service. I knew wsdl2java and that helped a bit but it created a whole bunch of classes and abstractions and stuff.

I understand the idea behind WSDL and all the XMLSchema stuff that's used in SOAP. It's to create a service and it's specification so that others can call it without problems. But I don't think that's the way to do it.

If you've got the choice take REST! REST is the real "Simple Object Access Protocoll" as it really is simple. And it can also use XML as a message format, even though you wouldn't want to. REST with JSON is the way to go. You only need to understand HTTP to understand REST, IMHO.