11

I use RestKit to interact with a REST api. For some of the actions, like HTTP PUT/POST/DELETE, I only care about the response status code (200, or 500 etc), and don't care about the response data, even though the API does send back data.

For performance consideration, is there a way to configure RestKit to avoid mapping the response? It seems that if I don't set up a response descriptor I am getting the error "no response descriptors match the response loaded"

yichen
  • 501
  • 1
  • 8
  • 15

3 Answers3

20

My solution was just to use a mapping for an NSObject

RKObjectMapping * emptyMapping = [RKObjectMapping mappingForClass:[NSObject class]];
RKResponseDescriptor * responseDescriptor = [RKResponseDescriptor responseDescriptorWithMapping:emptyMapping
                                                                                         method:RKRequestMethodPOST
                                                                                    pathPattern:API_SURVEY_UPLOAD keyPath:nil
                                                                                    statusCodes:[NSIndexSet indexSetWithIndex:200]];
[objectManager addResponseDescriptor:responseDescriptor];
deepwinter
  • 4,568
  • 2
  • 31
  • 37
  • Yes this works, but RestKit still logs an error (without crashing), "dding mapping error: No mappable values found for any of the attributes or relationship mappings" - Isn't there something more elegant? – Andy Obusek Dec 31 '13 at 19:11
  • 7
    Use [NSNull class] instead, that should remove the warning – Gabriel Cartier Jul 30 '14 at 06:43
8

If you don't need to map the response data to objects nor map objects to request params, you might be interested in using AFHTTPClient, which is what RestKit 0.20 uses anyway. You can access the AFHTTPClient object that RestKit itself uses, so you don't have to set up the base URL or authentication headers, etc. yourself all over again.

Here's a simple GET example:

[[[RKObjectManager sharedManager] HTTPClient] getPath:@"http://example.com"
                                           parameters:nil
                                              success:^(AFHTTPRequestOperation *operation, id responseObject) {
                                                  // handle success
                                              }
                                              failure:^(AFHTTPRequestOperation *operation, NSError *error) {
                                                  // response code is in operation.response.statusCode
                                              }];
nioq
  • 3,215
  • 1
  • 23
  • 18
  • Although this is a good workaround, you'd still have to delete the object manually from core data after the request was successful, hence loosing a bit of the power of Reskit. I still voted up, but the answer above with an [NSNull class] seems like the best answer. – Gabriel Cartier Jul 30 '14 at 06:44
  • Actually since this approach uses AFHTTPClient, the response won't get mapped to anything in core data so there's nothing that needs to be manually deleted after success. There is however a new downside to using the HTTPClient object from RestKit: AFNetworking 2.0 no longer has AFHTTPClient. Although RestKit is still using AFNetworking 1.3, it will probably get updated eventually and pointing to the deprecated HTTPClient will likely add to the migration effort later on. – nioq Jul 30 '14 at 15:24
  • My bad, I meant this, that the mapping won't be done so you have to do this manually. Disregard the delete comment (I was too much into my code), I meant exactly what you said – Gabriel Cartier Jul 30 '14 at 16:12
5

No, as the error suggests you need some response descriptor defined. It doesn't need to be complex (it can map a single data item like a status flag into an NSDictionary).

Don't worry about performance until you have reason to (profiling shows a problem).

That said, the most efficient way for RestKit to operate (at runtime) is to not have multiple response descriptors to search through, so be as specific as you can with path patterns and keypaths.

Wain
  • 118,658
  • 15
  • 128
  • 151