Moving object graph between a new iPhone app and a new Rails 3 backend

Question

I know this question has been answered a million times over the years... but times, and technologies, change quickly...so looking for "fresh" data ;-)

I'm seeking advice on a robust, and relatively straight forward, approach toward moving fairly complex objects from a Rails 3 back-end to an iPhone 3(4) app. There is no pre-existing API (xml/json/soap/etc) to adhere to so we can pick a frontrunner that's easy, flexible, fast and easy to maintain. Wishful thinking?!?

App will be getting entity objects from Rails that are somewhat complex. Each entity will be a nested group of related objects. I've had success with using json-framework and transferring simple objects back and forth... But we need a way to pass an object tree (or root object) and all its limbs and branches. and then de-serialize them back in iOS... and vice-versa (though to a lesser degree moving data back to the server).

ObjectiveResource seemed somewhat promising but doesn't appear to have been updated in over a year?!?

We could roll our own. But which technology to favor? Rails does xml & json natively while iPhone does plists natively. There are plist and plistifier gems for Rails and TouchJSON, json-framework, ObjectiveResource for iOS (among others).

I don't have much experience with any of these so looking for some advice one way or another...or something even better/easier?

Answer 1

Meltemi

I wrote an iPhone app that represents a store for an online retailer. Their needs included a category tree structure, product objects with review and detail trees, etc. I used RAILS as the REST server and JSON for everything because (1) JSON meant less bytes over the wire, (2) easy to serialize and deserialize into NSDictionary and NSArrays and (3) native RAILS works great.

Used the SBJSON libraries from http://stig.github.com/json-framework/. Tried others but these are the fastest and most reliable.

Did look at XML (their old servers were MS IIS Servers) and SOAP, but they were all data heavy and slow.

Hilton

Answer 2

I would agree that REST and JSON would be the default approach. Also of interest are some of the emerging binary protocols like Apache Thrift and Google's Protocol Buffers, if the idea of using IDLs in 2010 doesn't trigger raging fits of PCSD (Post-COM Stress Disorder). I would think these would only be an option if performance and bandwidth were really at a premium for your app.