RestKit: pros and cons


I would like to know the opinion of colleagues about the RestKit library.

It is the real experience of using the library that interests, and not the links to the project on GitHub or the documentation : I have already become quite familiar with the documentation and read several posts by the author of the library on SO ( this one turned out to be especially informative).

After reviewing all the material on RestKit most valuable code in the library seemed to me the code, the so-called. Object Mappings Engine , which solves the problem of automatically associating JSON objects with Core Data models based on automatic recognition of the property types of the corresponding objects:

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.

… which looks like a very attractive opportunity to stop creating large amounts of corresponding code by hand and rely on AFNetworking probably the second most popular project in Objective-C after AFNetworking among the projects related to Networking and REST with huge community and activity. At a minimum, there is a temptation to steal the Mapping Engine – I consider this option, because I feel very comfortable with all the other participants in this scheme: AFNetworking , Core Data , Concurrency (GCD + NSOperation + Threads) .

Your experience is very interesting, edge cases are especially interesting (for example, I had to abandon Restkit for this and that, or, conversely, cases like " RestKit saved us from certain death for many years to come") and especially interesting cases of using RestKit in complex projects (a lot of network interaction, a variety of data, etc.).

Thank you.

PS It is interesting to hear the personal opinion of @AlexDenisov , he is clearly in the know;)


Even though there is already an accepted answer in this thread, I would welcome any other answers describing a real-world experience with RestKit. Thank you.


I noticed RestKit a long time ago, when it was still version 0.10.x, but I managed to use it in a real project only about six months ago, in fact, it was my first experience, rather sad. About a month and a half ago I started working on a new project, and there I use RK, this is my second experience, there is much less sadness.

tl; dr

  1. RestKit is very cool and convenient, provided you have a truly RESTful API.
  2. As with all software, it contains bugs, and sometimes very unusual ones.

First experience

A new project, the PM came and said "Write specs to the API, the guys will do". Joy was immeasurable. We spent two days on specs with a team of three people. The specs were ready, RESTful, all the cases. After that I started writing tests for apihu on stubs, wrote for three days, was insanely happy.

And then the first endpoints on the server gradually began to appear, and the apiha did not completely correspond to what we described in the specs.

Instead of one resource with GET / POST / etc, there were 4: getProducts, createProduct, etc …

I did not dare to cut out RK, and began to adapt it for a real apish, here I ran into its main disadvantage: it works perfectly if you have a really RESTful API (in fact, for this reason, I could not use it for such a long time).

In principle, it worked in our case as well, but it was an overhead: we had to describe descriptors several times for different paths of the same entity. And the tests had to be thrown out, because maintaining them with such an API was a very time-consuming task.

Second experience

A new project, next to the guys who are writing API, the purest RESTful API.

At first, even with an even rest, it seemed that there was some kind of overhead, because in the first days I wrote a lot of code for mappings, routes and descriptors, but after almost a month when all the api were described, working with the network became just a pleasure, literally three lines – and that's it, we are waiting for our models or errors (which are also very conveniently mapped in the model).

Of the minuses: I suddenly ran into a problem , at first there were thoughts to rewrite the apishku, until it rolled off to the production, but I decided to wait and started looking for a problem.

The solution surprised me a lot: in fact, I changed a rather serious part of the code, but not a single test failed.

In the end, I'm still waiting, maybe I'll have to rewrite this piece of apiha, so as not to drag around with the patched version.

PS I apologize for such a large volume and confusion of presentation


Repeated requests

I did not come across such a topic especially, the only similar situation:

send a request for an authorized resource, 401 Unauthorized is received in response, send a login / pass to the server, get a token and send the first request again.

Honestly, I don’t know if RK has such a possibility, but my colleague processed this case in a simple way: if 401 comes in somewhere, then the processing goes to another branch, where all these requests are executed.

The only "rake" in this solution is that you have to create a new RKRequestOperation (since the old one is cached, and you won't be able to send it again) and send it to the queue enqueueRequestOperation: ( enqueueRequestOperation: .

But in general, you need to carefully look at the docks / sources, I have not yet had time to face such a task 🙂

Scroll to Top