Concerns about 0.20

[Nick Curran]

I've been reading the Upgrading from 0.10 to 0.20 document on the wiki, and I have some concerns regarding the new API for loading, namely getObjectsAtPath... v. loadObjectsAtResourcePath....

Without the loader block, how do I specify a mapping to be used on that specific operation? I currently map the same path to different objects with different mappings based on context, and with the soon to be old way, I am able to do that by setting loader.objectMapping inside the loader block.

It's also been convenient for service operations that return a 204 no content result to set a block on loader.onDidLoadResponse instead of loader.onDidLoadObject. I still want loader.onDidFailWithError, because for server exceptions, I still want the mapped object specified by my global errorMapping.

What would the approach be to handling these scenarios in the 0.20? Are the old methods going to be totally deprecated  The new approach seems a bit more concise but less flexible.

[Blake Watters]

Hi Nick -

Each RKObjectRequestOperation determines how to perform mapping by evaluating the response of the HTTP request against the array of RKResponseDescriptor objects with which it was initialized. When you obtain an object request operation from the manager, it gets initialized with all of the RKResponseDescriptor objects that could possibly match (based on the path pattern). Once the response is loaded, the response descriptors are enumerated to find matches for the response payload and then they are handed off to the response mapper operation for processing.

For your case, you will probably want to obtain an operation directly, configure the mapping descriptors, and then enqueue it. If you want to preserve the one-liner use of getObjectsAtPath, you can subclass the object manager and encapsulate your specific logic into that subclass. I've tried to provide very sensible defaults for most straightforward use-cases but exposed all of the lower level primitive methods that will let you customize and create your own versions of the methods very easily. If you read the source code for RKObjectManager, you'll see that most of the getObjectsAtPath, put/postObject, etc. are all very short and rely on smaller bites of functionality implemented in other public methods on the manager.

If you get a 204 response, the success block is still going to be invoked, even if no mapping was performed. Error mapping has been generalized to use the response descriptor concept such an error mapping is just a mapping that happens to target a status code in the 4xx or 5xx status code range. 

If you do want to really customize the HTTP handling in some way, you can register a custom subclass of RKHTTPRequestOperation on the manager. The object request operations are really just aggregate operations that run an HTTP request operation to completion, then takes the response body and runs it through an instance of RKResponseMapperOperation. If you subclass RKHTTPRequestOperation and register it on the manager, your subclass will be used for all HTTP transport for requests made through the manager. RKHTTPRequestOperation is a subclass of the AFNetworking URL connection operation, meaning that it implements the NSURLConnectionDelegate and as such has full access to entire lifecycle of the URL connection. Whatever response and error values are exposed by the HTTP operation are what flows into the response mapper.

I think you'll actually find things to be more flexible once you get oriented in the new code base. Things are much less monolithic, so its easier to break things apart and use them to construct your own operations. 

[Nick Curran]

I appreciate the thorough response; it seems to clear things up for me and alleviate my concerns about upgrading at some point.

Will the 0.10.3 APIs break on upgrading or just get marked deprecated? It would be nice to be able to live in both worlds for a minor version or two.

[Blake Watters]

Nick -

I decided not to deal with deprecations in the API. There were too many changes across all of the API's and my goal with this release is to set the stage for 1.0 and be API stable with semantic versioning going forward.

I know its painful, but its taken me a long time to figure out how to get these API's right.

[Nick Curran]

Understandable. Thanks for responses. Thanks also for your work on RestKit, it's been a godsend for us.