gowalla/AFNetworking — Issue #83: AFHTTPClient success/failure callbacks should pass back similar information
Author: evanlong
Created: 2011-10-19 22:22:55+00:00
State: open

Currently the `AFHTTPClient` success callback for the get/put/post/delete accepts an `id object` which is the parsed object from the body of the response. The failure callbacks take a `(NSHTTPURLResponse*, NSError*)`. For the success callbacks it is currently not possible to get the status code of the response. It is only possible to get the parsed object. For the failure callbacks it is possible to get the status code from the `NSHTTPURLResponse` and in some cases the `NSError` (failures that have no HTTP response wouldn't have a status code). However, in the failure callback it is not possible to get the body of the response. `NSHTTPURLResponse` doesn't contain anything related to the body of the response. The reason this is an issue is that sometimes 4xx responses contain more detailed error information in the body. Take for example the facebook request: `http://graph.facebook.com/4?access_token=foobar`. It will return a status code of 400 and the body has more error information (requires https).

I would propose the following change:

* success callback would have the following interface: `success(AFHTTPResponse *response)`
* failure callback would have the following interface: `failure(AFHTTPResponse *response, NSError *error)`
* The response for this callback could be nil under errors that do not receive a response (eg: loss of internet, or timeouts). The error should always be set.

The `AFHTTPResponse` might look something like this:

```objective-c
@interface AFHTTPResponse : NSObject {
NSInteger statusCode;
NSHTTPURLResponse *response;
NSData *rawBody;
id parsedBody; // parsed XML, JSON, HTML tree, (could be nil if parse fails or if parsing is disabled)
}
```

Not only would using something like `AFHTTPResponse` address the issues I outlined above but would also help prevent breaking API changes for the `AFHTTPClient` going forward. New details or different parameters could be passed to the success/failure callbacks by adding a property to the `AFHTTPResponse`.

Making this change would break the current API so I would love to get some feedback on this. I am also open to giving the first implementation a go as well provided folks think this is the right direction.