Перемещение графа объектов между новым приложением iPhone и новым бэкэндом Rails 3

Question

Я знаю, что на этот вопрос отвечали миллион раз за эти годы ... но времена и технологии быстро меняются ... поэтому я ищу "свежие" данные; -)

Я ищусоветы по надежному и относительно простому подходу к перемещению довольно сложных объектов из серверной части Rails 3 в приложение для iPhone 3 (4).Не существует ранее существовавшего API (xml / json / soap / etc), к которому мы могли бы присоединиться, чтобы мы могли выбрать простой, гибкий, быстрый и простой в обслуживании лидер.Желаемое за действительное?

Приложение будет получать объекты сущностей из Rails, которые являются довольно сложными.Каждая сущность будет вложенной группой связанных объектов.У меня был успех с использованием json-framework и передачей простых объектов назад и вперед ... Но нам нужен способ передать дерево объектов (или корневой объект) и все его ветви и ветви.а затем десериализовать их обратно в iOS ... и наоборот (хотя в меньшей степени перенести данные обратно на сервер).

ObjectiveResource показалось несколько многообещающим, но неПохоже, что были обновлены в течение года?!?

Мы могли бы катиться самостоятельно.Но какую технологию отдать предпочтение? Rails изначально выполняет xml & json , в то время как iPhone выводит исходные данные .Существуют plist и plistifier гемов для Rails и TouchJSON , json-framework , ObjectiveResource для iOS (средидругие).

У меня нет большого опыта с любым из них, поэтому ищу какой-то совет так или иначе ... или что-то еще лучше / проще?

Answer 1

Meltemi

Я написал приложение для iPhone, которое представляет собой магазин для интернет-магазина.Их потребности включали структуру дерева категорий, объекты продукта с деревьями обзора и детализации и т. Д. Я использовал RAILS в качестве сервера REST и JSON для всего, потому что (1) JSON означал меньше байтов по проводам, (2) легко сериализовался и десериализовался вNSDictionary и NSArrays и (3) native RAILS прекрасно работает.

Использовал библиотеки SBJSON из http://stig.github.com/json-framework/. Пробовал другие, но это самые быстрые и надежные.

Посмотрел XML(их старыми серверами были MS IIS Servers) и SOAP, но все они были тяжелыми и медленными.

Hilton

Answer 2

Я бы согласился, что REST и JSON будут подходом по умолчанию. Также представляют интерес некоторые новые бинарные протоколы, такие как Apache Thrift и Google Protocol Buffers , если идея использования IDL в 2010 году не вызывает бурных приступов PCSD (Пост- COM Стресс расстройства). Я думаю, что это было бы возможным, если бы производительность и пропускная способность действительно были выше для вашего приложения.