I’m going to be creating an internal app for the iPhone and iPad that will keep track of sales calls, the associated quotes, photos, and drawings for those quotes. I’m still in the concept design phase and I’m trying to read up on the different ways to communicate between my app and the webservice. Obviously since this will be used mostly over 3G or … Edge I want an efficient protocol so my gut reaction is to stay away from XML based things like XML-RPC, or SOAP. I would like to use PHP and MySQL on the server and plan on using Core Data on iOS.
So I have a couple specific questions:
- What scheme should I use for performance?
- What scheme should I use for ease of working with on the server?
- What scheme should I use for ease of working with on iOS?
- What scheme should I use considering the project as a whole?
- Is using an XML based scheme better despite the network overhead? Why?
Given the way you’ve asked multiple questions you probably realize that the ultimate solution you use will be a balancing act between competing goals.
1: You need to define “performance” better. I’m assuming you’re referring to network transmission time which means keeping server latency low and number of bytes transmitted low. The ultimate is probably a custom binary wire protocol that’s also been analyzed for compressibility and compression applied where appropriate (e.g. repeated strings or sequences). The downside to such a protocol is that it will likely be more difficult to code on both server & client since you won’t be able to use SDK support for standardized encodings, and unless thoughtfully designed binary protocols tend to be brittle for supporting future changes and extensions to your application.
Also you should consider how you define the transactions of your protocol, even with an efficient encoding if your protocol requires many round trips vs. a single round trip you’ll still be slow.
Lastly depending on the size of the data you’re sending, the overhead of an encoding may be immaterial compared to the size of the data.
I recommend sticking with a standardized encoding format which can be parsed with library support, which narrows the field to two major grammars: XML or JSON.
2: XML and JSON both are well supported in server frameworks. When using XML services I recommend a REST style pattern as they’re usually easy to build and you don’t have to conform your application to somebody else’s style.
I would stay away from SOAP-based web services even though building them may be well supported (especially on Windows platforms), because the complexity of doing a full SOAP-based parse on the mobile client is high and not well supported there. I don’t find automatically generated object serialization by WSDL compilers to be that big of a win for saving time when coding, it is usually pretty easy to serialize to a REST-style XML or often even simpler for JSON.
3: iOS supports a built-in SAX style XML parser, and there a variety of class libraries available that support in-memory DOM implementations with different features and speed levels. Pick the one best for your needs. I personally prefer TBXML which is fast, fairly lightweight, and easy to program to, but because it does not validate schemas and it is an in-memory tree, it is not appropriate in some situations. Here is a shootout of iOS XML library performance.
There are several JSON libraries available for iOS if you Google around. Or look in this answer.
SOAP is not well supported and there are limited library choices. You can always hand-parse the SOAP responses generated by a server but it is brittle to server-side changes that are legal SOAP (e.g. different namespace prefixes) that could break a hardcoded XML parser.
4: Difficult to answer without knowing more about your project’s details, but I’d lean towards a JSON or simple XML-based encoding because: both are usually easy to program to on client and server, both can be done with reasonable efficiency on the wire, and are likely to be extensible for future app iterations.
JSON has advantages of being a bit simpler to parse, can be less wordy, and may also be easier to re-task for other purposes, such as building an Ajax web client on top of your services.
5: XML vs JSON vs. other encodings? I think this is a personal preference. XML can be more self-describing than JSON but is likely to be more work to parse. JSON can be lower overhead in raw bytes and is easy to parse. Again the encoding overhead may be significant or may be negligible depending on the size of your content. Also you can apply external compression in any case.