How SOAP and REST work with XML/JSON response?

Question

This is one very common question asked again and again on stack overflow and I read so many answers about this but I am still bit confused.

I need to call the webservices from iPhone sdk.

Here are my questions:

1. I am not clear what response SOAP or REST return.Is there anything specific that if response is XML then we should use REST and if JSON we should use SOAP?

2. What is the role of ASIHTTP with SOAP and REST?

3. If I am getting XML response as

<oproduct>
    <iid>113133791</iid>
    <icategoryid>270</icategoryid>
    <imerchantid>1547</imerchantid>
    <iadult>0</iadult>
    <sname>The Ashes / 1st Test - England v Australia - Day 1</sname>
    <sawdeeplink>http://www.acbcd.com/pclick.php?p=113133791&amp;a=111402&amp;m=1547&amp;platform=cs</sawdeeplink>
    <sawthumburl>http://images.abcdd.com/thumb/1547/113133791.jpg</sawthumburl>
    <fprice>69.99</fprice>
  </oproduct>

Do I need to parse it by hand? or how do I handle XML response?

I got so many articles about REST and SOAP but no proper code to understand it. I would be grateful for any help regarding these questions.

Answer 1

SOAP - "Simple Object Access Protocol"

SOAP is a method of transferring messages, or small amounts of information, over the Internet. SOAP messages are formatted in XML and are typically sent using HTTP (hypertext transfer protocol).

So SOAP has a standard how a message has to be sent.

Each soap web service can be defined with a WSDL(Web Service Definition Language) which is kind of a schema for the SOAP XML transferred.

There are many tools available to convert WSDL(your webservice definition) to native code.

One of the tool available for ObjC is Sudz-C (http://sudzc.com/) which convert the WDSL of any webservice to ObjC code to access the Web service.

---

Rest - Representational state transfer

Rest is a simple way of sending and receiving data between client and server and it don't have any much standards defined , You can send and receive data as JSON,XML or even a Text. Its Light weighted compared to SOAP.

To handle Rest in iOS there are many tools available, I would recommend RestKit http://restkit.org/, for handling XML and JSON both.

I would suggest you to go with Rest for mobile development, since its light weight

(Simple example, People correct me If I am wrong)

Answer 2

Ok, so you have a few different questions here:

1. REST is a way of accessing the web service. SOAP is an alternative way of accessing the web service. REST uses query string or URL format whereas SOAP uses XML. JSON and XML are two different ways of sending back data. SOAP and XML are usually associated with each other. For mobile apps, REST/JSON is usually the way to go. Easier to implement and maintain, far more telegraphic, etc.

2. ASIHTTP, as Bill notes, is a wrapper. There are other choices that do similar things depending on what you need. If you are using REST/JSON then NSURLConnection + SBJSON might do the trick, I like it personally.

3. If your SOAP service has an available WSDL you can use wsdl2objc to automatically build the code for your parsing and fetching. If it is a JSON service or no WSDL is available, I would recommend using SBJSON and simply parsing in the following way:

   for (id jsonElement in repsonse) { self.propertyA = [jsonElement valueForKey:@"keyA"]; self.propertyB = [jsonElement valueForKey:@"keyB"]; }

Hope that helps!

Answer 3

1) SOAP responses must be XML, and to return other formats you need to either embed them in the response XML (inefficient) or use SOAP attachments (difficult). SOAP responses are contained in a soap envelope tag, and there is usually an associated wsdl. If the XML you show is all you're getting, then it may not be a SOAP service. I see links in the XML so that is a good sign that they had REST in mind.

2) I haven't heard of ASIHTTP. A quick google, and it looks like its a third party library that wraps the http interfaces in iOS. It looks like you would use that to help you make the http requests, although I would suggest that it might not be necessary; you should evaluate using the http libraries directly.

3) You need to parse it somehow. You can do it by hand, but that is generally a really bad idea. XML can come in many forms and still have the same meaning, and if you don't support all forms your application could break in the future if the web service provider began to format their XML differently, even if its semantics were the same. You would use an XML api to read the XML. The DOM api will read it into a tree form for you, and you can use XPath to extract information out of the tree.