JSON or SOAP (XML)?

user_148988 0
Viewed 37507

I'm developing a new application for the company. The application have to exchange data from and to iPhone.

Company server side uses .NET framework.

For example: the class "Customer" (Name, Address etc..) for a specific CustomerNumber should be first downloaded from server to iphone, stored locally and then uploaded back to apply changes (and make them available to other people). Concurrency should not be a problem (at least at this time...)

In any case I have to develop both the server side (webservice or whatever) and the iPhone app.

I'm free to identify the best way to do that (this is the application "number ONE" so it will become the "standard" for the future).

So, what do you suggest me ?

Use SOAP web services (XML parsing etc..) or user JSON ? (it seems lighter...) Is it clear to me how to "upload" data using SOAP (very long to code the xml soap envelope ... I would avoid) but how can I do the same using JSON ?

The application needs to use date values (for example: last_visit_date etc..) what about date in Json ?

objective-c soap iphone json
7 Answers

JSON has several advantages over XML. Its a lot smaller and less bloated, so you will be passing much less data over the network - which in the case of a mobile device will make a considerable difference.

Its also easier to use in javascript code as you can simply pass the data packet directly into a javascript array without any parsing, extracting and converting, so it is much less CPU intensive too.

To code with it, instead of an XML library, you will want a JSON library. Dates are handled as you would with XML - encode them to a standard, then let the library recognise them. (eg here's a library with a sample with dates in it)

Here's a primer.

user_137440

Ah, the big question: JSON or XML?

In general, I would prefer XML only when I need to pass around a lot of text, since XML excels at wrapping and marking up text.

When passing around small data objects, where the only strings are small (ids, dates, etc.), I would tend to use JSON, as it is smaller, easier to parse, and more readable.

Also, note that even if you choose XML, that does not by any means mean you need to use SOAP. SOAP is a very heavy-weight protocol, designed for interoperability between partners. As you control both the client and server here, it doesn't necessarily make sense.

Avi_16050

Consider how you'd be consuming the results on the iPhone. What mechansim would you use to read the web service response? NSXMLParser?

How you consume the data would have the biggest impact on how your serve it.

Are JSON and SOAP your only options? What about RESTful services?

Take a look at some big players on the web that have public APIs that are accessible by iPhone clients:

Twitter API FriendFeed API

Also, review the following related articles:

user_1023450

JSON has following advantages:

  1. it can encode boolean and numeric values ... in XML everything is a string
  2. it has much clearer semantics ... in json you have {"key":"someValue"}, in XML you can have <data><key>someValue</key></data> or <data key="someValue" /> ... any XML node must have a name ... this does not always make sense ... and children may either represent properties of an object, or children, which when occuring multiple times actually represent an array ... to really understand the object structure of an XML message, you need its corresponding schema ... in JSON, you need the JSON only ...
  3. smaller and thus uses less bandwidth and memory during parsing/generation ...

apart from that, i see NO difference between XML and JSON ... i mean, this is so interchangable ... you can use JSON to capture the semantics of SOAP, if you want to ... it's just that SOAP is so bloated ... if you do want to use SOAP, use a library and generators for that ... it's neither fun nor interesting to build it all by hand ...

using XML RPC or JSON RPC should work faster ... it is more lightweight, and you use JSON or XML at will ... but when creating client<->server apps, a very important thing in my eyes, is to abstract the transport layer on both sides ... your whole business logic etc. should in no way depend on more than a tiny interface, when it comes to communication, and then you can plug in protocols into your app, as needed ...

user_1114660

There are more options than just SOAP vs JSON. You can do a REST-based protocol (Representational State Transfer) using XML. I think it's easier use than SOAP and you get a much nicer XSD (that you design.) It's rather easy for almost any client to access such services.

On the other hand, JSON parsers are available for almost any language and make it really easy to call from JavaScript if you'll use them via AJAX.

However, SOAP can be rather powerful with tons of standardized extensions that support enterprise features.

user_1514070
Related