What is a good design pattern / lib for iOS 5 to synchronize with a web service?
Without going into detailed specifics, the application allows the user to estimate the costs of work at a remote site. These costs are broken down by room and item. If the user was an internet connection this data can be sent back to the server.
Multiple photographs can be taken of each item, but they will be held in a separate queue, which sends when the connection is optimal (ideally wifi).
Finally, our backend application controls the unique ids for each room and item. Thus, each time we send these costs to the server, the server echoes the central database ids back, thus, that they can be synchronized in the mobile app. I have simplified this a little, since the operations contract is actually much larger, but I just want to illustrate the basic requirements without complicating matters.
Firstly, the web service architecture: We currently have a GetCosts and UpdateCosts operations.
My assumption is that if we used a strict REST architecture we would need to break our single web service operations into multiple smaller services. This would make the services much more chatty and we would also have to guarantee a delivery order from the app. For example, we need to make sure that containing rooms are added before the item.
Although this seems much more RESTful, our perception is that these extra calls are expensive connections (security checks, database calls, etc). Does the type of web api (operation over service focus) determine chunky vs chatty? Since this is mobile (3G), are we better handling lots of smaller messages, or a few large ones?
Secondly, the iOS side. We are primarily looking to the HN community's vast experience in developing native mobile apps (iOS 5 is our focus), with advice on how to manage data synchronization within the iOS app itself. We need multiple queues and we need to guarantee delivery order in each queue (and technically, ordering between queues). The server needs to control unique ids and other properties and echo them back to the application. The application then needs to update an internal database and when re-updating, make sure the correct ids are available in the update message (essentially multiple inserts and updates in one call).
Our backend has a ton of business logic operating on these cost estimates. We don't want any of this in the app itself.
I welcome any advice you might have.