How to post a webservice request from an xcode project

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?

---

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