Ole Begemann

iOS Development

On NSURLConnection API Design

Today I learned that Apple’s NSURLConnection class was originally written for the first release of Safari in 2003.1 I had always wondered why the NSURLConnection API was designed as it is. Now that I know it was specifically designed for a web browser, it suddenly makes much more sense.

Web Browsers vs. Talking to Web Services

Over the last ten years, very few users of NSURLConnection have probably used it to actually implement a web browser. The large majority of developers use the API to talk to a web service of some kind. These are two very different use cases with vastly different requirements:

The original goals for NSURLConnection still show in its API design today. Contrast this with a modern networking library like AFNetworking, which has been designed from the start with web services in mind. Consequently, it handles HTTP 4xx and 5xx status codes as errors and comes with an extensible system for dealing with different response types like XML, JSON or images.

It’s no wonder there are so many third-party networking libraries for Cocoa because the built-in API is arguably not the perfect fit for the most common use cases.

Design Your API for the Most Important Use Case

API design is very much influenced by the goal the API is intended to accomplish. This is, of course, hardly a surprise and definitely not a bad thing. When designing your own API, it helps to define this goal explicitly. Make sure your design makes implementing the most common use cases you expect especially easy. When you find yourself having a hard time grasping an API others have written, learning about their original design goal may help you better understand why the API has been designed in a particular way.

  1. Source: WWDC 2013 session 705.

  2. Redirects are an exception. It’s no surprise then that NSURLConnection can handle HTTP redirects automatically.