Question

I’m trying to generate a web service call from my iphone app.

I’m working with web services for the the first time.

I realize that an SOAP request would something like this:

My actual web service is not on local.

POST /MyFirstWebService.asmx HTTP/1.1
Host: localhost
Content-Type: text/xml; charset=utf-8
Content-Length: length
SOAPAction: “http://tempuri.org/HelloWorld“

<?xml version=”1.0″ encoding=”utf-8″?>
<soap:Envelope
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance&gt;

xmlns:xsd=”http://www.w3.org/2001/XMLSchema&#8221;
xmlns:soap=”http://schemas.xmlsoap.org
/soap/envelope/”>

<soap:Body>
<HelloWorld xmlns=”http://tempuri.org/&#8221; />
</soap:Body>
</soap:Envelope>

I want the string hello world returned from the web service.

What is the best way to do this?

I have also read about a framework called JSON.

Can that be useful here?

Answer 1

This link provides simple explaination of how to consume web service in iphone it also explains simple post simple Get and SOAP

Consuming Web Services in iPhone Applications

Difference Between Soap and REST

SOAP and RESTful web services have a very different philosophy from each other. SOAP is really a protocol for XML-based distributed computing, whereas REST adheres much more closely to a bare metal, web-based design. SOAP by itself is not that complex; it can get complex, however, when it is used with its numerous extensions (guilt by association).

To summarize their strengths and weaknesses:

* SOAP *

Pros:

Langauge, platform, and transport agnostic
Designed to handle distributed computing environments
Is the prevailing standard for web services, and hence has better support from other standards (WSDL, WS-*) and tooling from vendors
Built-in error handling (faults)
Extensibility

Cons:

Conceptually more difficult, more “heavy-weight” than REST
More verbose
Harder to develop, requires tools

* REST *

Pros:

Language and platform agnostic
Much simpler to develop than SOAP
Small learning curve, less reliance on tools
Concise, no need for additional messaging layer
Closer in design and philosophy to the Web

Cons:

Assumes a point-to-point communication model–not usable for distributed computing environment where message may go through one or more intermediaries
Lack of standards support for security, policy, reliable messaging, etc., so services that have more sophisticated requirements are harder to develop (“roll your own”)
Tied to the HTTP transport model