Classes

AFSecurityPolicy evaluates server trust against pinned X.509 certificates and public keys over secure connections.

Adding pinned SSL certificates to your app helps prevent man-in-the-middle attacks and other vulnerabilities. Applications dealing with sensitive customer data or financial information are strongly encouraged to route all communication over an HTTPS connection with SSL pinning configured and enabled.

AFNetworkReachabilityManager monitors the reachability of domains, and addresses for both WWAN and WiFi network interfaces.

Reachability can be used to determine background information about why a network operation failed, or to trigger a network operation retrying when a connection is established. It should not be used to prevent a user from initiating a network request, as it’s possible that an initial request may be required to establish reachability.

See Apple’s Reachability Sample Code ( https://developer.apple.com/library/ios/samplecode/reachability/ )

AFHTTPRequestSerializer conforms to the AFURLRequestSerialization & AFURLResponseSerialization protocols, offering a concrete base implementation of query string / URL form-encoded parameter serialization and default request headers, as well as response status code and content type validation.

Any request or response serializer dealing with HTTP is encouraged to subclass AFHTTPRequestSerializer in order to ensure consistent default behavior.

AFJSONRequestSerializer is a subclass of AFHTTPRequestSerializer that encodes parameters as JSON using NSJSONSerialization, setting the Content-Type of the encoded request to application/json.

AFPropertyListRequestSerializer is a subclass of AFHTTPRequestSerializer that encodes parameters as JSON using NSPropertyListSerializer, setting the Content-Type of the encoded request to application/x-plist.

AFHTTPResponseSerializer conforms to the AFURLRequestSerialization & AFURLResponseSerialization protocols, offering a concrete base implementation of query string / URL form-encoded parameter serialization and default request headers, as well as response status code and content type validation.

Any request or response serializer dealing with HTTP is encouraged to subclass AFHTTPResponseSerializer in order to ensure consistent default behavior.

AFJSONResponseSerializer is a subclass of AFHTTPResponseSerializer that validates and decodes JSON responses.

By default, AFJSONResponseSerializer accepts the following MIME types, which includes the official standard, application/json, as well as other commonly-used types:

• application/json
• text/json
• text/javascript

In RFC 7159 - Section 8.1, it states that JSON text is required to be encoded in UTF-8, UTF-16, or UTF-32, and the default encoding is UTF-8. NSJSONSerialization provides support for all the encodings listed in the specification, and recommends UTF-8 for efficiency. Using an unsupported encoding will result in serialization error. See the NSJSONSerialization documentation for more details.

AFXMLParserResponseSerializer is a subclass of AFHTTPResponseSerializer that validates and decodes XML responses as an NSXMLParser objects.

By default, AFXMLParserResponseSerializer accepts the following MIME types, which includes the official standard, application/xml, as well as other commonly-used types:

• application/xml
• text/xml

AFPropertyListResponseSerializer is a subclass of AFHTTPResponseSerializer that validates and decodes XML responses as an NSXMLDocument objects.

By default, AFPropertyListResponseSerializer accepts the following MIME types:

• application/x-plist

AFImageResponseSerializer is a subclass of AFHTTPResponseSerializer that validates and decodes image responses.

By default, AFImageResponseSerializer accepts the following MIME types, which correspond to the image formats supported by UIImage or NSImage:

• image/tiff
• image/jpeg
• image/gif
• image/png
• image/ico
• image/x-icon
• image/bmp
• image/x-bmp
• image/x-xbitmap
• image/x-win-bitmap

AFCompoundSerializer is a subclass of AFHTTPResponseSerializer that delegates the response serialization to the first AFHTTPResponseSerializer object that returns an object for responseObjectForResponse:data:error:, falling back on the default behavior of AFHTTPResponseSerializer. This is useful for supporting multiple potential types and structures of server responses with a single serializer.

AFURLSessionManager creates and manages an NSURLSession object based on a specified NSURLSessionConfiguration object, which conforms to <NSURLSessionTaskDelegate>, <NSURLSessionDataDelegate>, <NSURLSessionDownloadDelegate>, and <NSURLSessionDelegate>.

Subclassing Notes

This is the base class for AFHTTPSessionManager, which adds functionality specific to making HTTP requests. If you are looking to extend AFURLSessionManager specifically for HTTP, consider subclassing AFHTTPSessionManager instead.

NSURLSession & NSURLSessionTask Delegate Methods

AFURLSessionManager implements the following delegate methods:

NSURLSessionDelegate

• URLSession:didBecomeInvalidWithError:
• URLSession:didReceiveChallenge:completionHandler:
• URLSessionDidFinishEventsForBackgroundURLSession:

NSURLSessionTaskDelegate

• URLSession:willPerformHTTPRedirection:newRequest:completionHandler:
• URLSession:task:didReceiveChallenge:completionHandler:
• URLSession:task:didSendBodyData:totalBytesSent:totalBytesExpectedToSend:
• URLSession:task:needNewBodyStream:
• URLSession:task:didCompleteWithError:

NSURLSessionDataDelegate

• URLSession:dataTask:didReceiveResponse:completionHandler:
• URLSession:dataTask:didBecomeDownloadTask:
• URLSession:dataTask:didReceiveData:
• URLSession:dataTask:willCacheResponse:completionHandler:

NSURLSessionDownloadDelegate

• URLSession:downloadTask:didFinishDownloadingToURL:
• URLSession:downloadTask:didWriteData:totalBytesWritten:totalBytesExpectedToWrite:
• URLSession:downloadTask:didResumeAtOffset:expectedTotalBytes:

If any of these methods are overridden in a subclass, they must call the super implementation first.

Network Reachability Monitoring

Network reachability status and change monitoring is available through the reachabilityManager property. Applications may choose to monitor network reachability conditions in order to prevent or suspend any outbound requests. See AFNetworkReachabilityManager for more details.

NSCoding Caveats

• Encoded managers do not include any block properties. Be sure to set delegate callback blocks when using -initWithCoder: or NSKeyedUnarchiver.

NSCopying Caveats

• -copy and -copyWithZone: return a new manager with a new NSURLSession created from the configuration of the original.

• Operation copies do not include any delegate callback blocks, as they often strongly captures a reference to self, which would otherwise have the unintuitive side-effect of pointing to the original session manager when copied.

AFHTTPSessionManager is a subclass of AFURLSessionManager with convenience methods for making HTTP requests. When a baseURL is provided, requests made with the GET / POST / et al. convenience methods can be made with relative paths.

Subclassing Notes

Developers targeting iOS 7 or Mac OS X 10.9 or later that deal extensively with a web service are encouraged to subclass AFHTTPSessionManager, providing a class method that returns a shared singleton object on which authentication and other configuration can be shared across the application.

Methods to Override

To change the behavior of all data task operation construction, which is also used in the GET / POST / et al. convenience methods, override dataTaskWithRequest:uploadProgress:downloadProgress:completionHandler:.

Serialization

Requests created by an HTTP client will contain default headers and encode parameters according to the requestSerializer property, which is an object conforming to <AFURLRequestSerialization>.

Responses received from the server are automatically validated and serialized by the responseSerializers property, which is an object conforming to <AFURLResponseSerialization>

URL Construction Using Relative Paths

For HTTP convenience methods, the request serializer constructs URLs from the path relative to the -baseURL, using NSURL +URLWithString:relativeToURL:, when provided. If baseURL is nil, path needs to resolve to a valid NSURL object using NSURL +URLWithString:.

Below are a few examples of how baseURL and relative paths interact:

NSURL *baseURL = [NSURL URLWithString:@“http://example.com/v1/”]; [NSURL URLWithString:@“foo” relativeToURL:baseURL]; // http://example.com/v1/foo [NSURL URLWithString:@“foo?bar=baz” relativeToURL:baseURL]; // http://example.com/v1/foo?bar=baz [NSURL URLWithString:@“/foo” relativeToURL:baseURL]; // http://example.com/foo [NSURL URLWithString:@“foo/” relativeToURL:baseURL]; // http://example.com/v1/foo [NSURL URLWithString:@“/foo/” relativeToURL:baseURL]; // http://example.com/foo/ [NSURL URLWithString:@“http://example2.com/” relativeToURL:baseURL]; // http://example2.com/

Also important to note is that a trailing slash will be added to any baseURL without one. This would otherwise cause unexpected behavior when constructing URLs using paths without a leading slash.