RestKit: за и против

#restkit #objective_c #ios #rest

Хотелось бы узнать мнение коллег о библиотеке RestKit.

Интересует именно реальный опыт использования библиотеки, а не ссылки на проект на
Гитхабе или документацию: я уже достаточно хорошо ознакомился с документацией и прочитал
несколько постов автора библиотеки на SO (особенно содержательным оказался этот).

После просмотра всего материала по RestKit наиболее ценным кодом в библиотеке мне
показался код, т.н. Object Mappings Engine, решающий задачу автоматического связывания
JSON-объектов с моделями Core Data на основе автоматического распознавания типов свойств
соответствующих объектов: 

RestKit leverages the highly dynamic Objective-C runtime to infer the developers
desired intent by examining the type of the source and destination properties and performing
appropriate type transformations.


...что выглядит очень привлекательной возможностью для того, чтобы перестать создавать
большие объёмы соответствующего кода руками и положиться на, наверное, второй по популярности
после AFNetworking проект на Objective-C среди проектов, связанных с Networking и REST
с огромной коммунити и активностью. Как минимум, возникает соблазн выкрасть Mapping
Engine, - я рассматваю такой вариант, так как очень комфортно себя чувствую со всеми
остальными участниками этой схемы: AFNetworking, Core Data, Concurrency (GCD + NSOperation
+ Threads).

Очень интересен ваш опыт, особенно интересны граничные случаи (например, пришлось
отказаться от Restkit потому-то и тому-то, или, наоборот, случаи вроде "RestKit спас
нас от верной гибели на долгие годы вперёд") и особенно интересны случаи употребления
RestKit в сложных проектах (много сетевого взаимодействия, разнообразие данных и пр.).

Спасибо.

P.S. Интересно услышать персональное мнение @AlexDenisov, он явно в курсе ;)

ОБНОВЛЕНО ПОЗЖЕ

Несмотря на то, что в этом топике уже есть принятый ответ, я буду рад любым другим
ответам, описывающим реальный опыт использования RestKit. Спасибо.
    

Ответы

Ответ 1

Я очень давно заметил RestKit, когда он еще был 0.10.х-ой версии, но использовать
его в реальном проекте удалось только около полугода назад, фактически это был мой
первый опыт, довольно печальный. Около полутора месяцев назад я начал работу над новым
проектом, и там я использую RK, это мой второй опыт, печали гораздо меньше.
tl;dr

RestKit очень крут и удобен при условии что у вас действительно RESTful API.
Как и во всем ПО в нем есть баги, причем порой очень необычные.

Опыт первый
Новый проект, пришел ПМ и сказал "Пишите спеки на API, ребята будут делать".
Радости было немеряно. На спеки мы командой из трех человек потратили два дня. Спеки
были готовы, RESTful, все дела. После я начал писать тесты на апиху на стабах, писал
дня три, был безумно счастлив.
И тут постепенно начали появляться первые endpoint'ы на серваке, причем апиха полностью
не соответствовала тому что мы описали в спеках. 
Вместо одного ресурса с GET/POST/etc было 4: getProducts, createProduct, etc...
Выпиливать RK я не решился, и стал адаптировать его под реальную апишку, здесь я
и столкнулся с главным его минусом: оно работает идеально если у вас действительно
RESTful API (собственно по этой причине я и не мог им пользоваться столь долгое время).
В принципе он сработал и в нашем случае, но это был оверхед: пришлось описывать descriptor'ы
по несколько раз для разных путей одной сущности. Да и тесты пришлось выкинуть, потому
что их поддержка с таким API была очень трудоемкой задачей.
Опыт второй
Новый проект, рядом ребята которые пишут API, чистейший RESTful API.
Поначалу даже с ровным рестом казалось что есть некий оверхед, потому как первые
дни писл много кода для маппингов, роутов и дескрипторов, но спустя почти месяц когда
все апи описано работа с сетью стала просто удовольствием, буквально три строчки -
и все, ждем наши модели или ошибки (которые тоже очень удобно мапятся в модели).
Из минусов: внезапно столкнулся с проблемой, сначала были мысли переписать апишку,
пока не укатилось на прод, но я решил подождать и начал искать проблему.
Решение меня очень удивило: по факту я изменил довольно серьезную часть кода, но
ни один тест не свалился.
В итоге все еще жду, возможно таки прийдется переписать этот кусок апихи, чтоб не
таскаться с патченой версией.
P.S. извиняюсь за столь большой объем и сумбурность изложения
UPD

Повторные запросы
Особо с такой темой не сталкивался, единственная похожая ситуация:
шлем запрос на авторизованный ресурс, в ответ приходит 401 Unauthorized, шлем логин/пасс
на сервер, получаем токен и повторно шлем первый запрос.
Честно говоря есть ли такая возможность у RK я не знаю, но мой коллега обрабатывал
этот кейс простым образом: если где-то приходит 401, то обработка уходит в другую ветку,
где и выполняются все эти запросы.
Единственные "грабли" в этом решении в том, что приходится создавать новый RKRequestOperation
(т.к. старый является закешированным, и повторно его послать не получится) и самому
отправлять его в очередь (enqueueRequestOperation:).
А в целом нужно внимательно посмотреть доки/исходники, я еще не успел столкнутся
с такой задачей :)