1
votes

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>
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org
/soap/envelope/">

<soap:Body>
<HelloWorld xmlns="http://tempuri.org/" />
</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?

1
I suspect you mean JSON (JavaScript Object Notation). It is a data format rather than a full framework and I think you should certainly be familiar with it before choosing something as heavyweight as SOAP. Take a look at www.json.org. If you're developing a web service what are your server side requirement and experience?Jonah

1 Answers

2
votes

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