Making Sense of the Internet

As a new iOS Developer that has just graduated from The Flatiron School, I ran into a situation where I was asked to explain how internet requests work. Here is what I’ve learned from the standpoint of a new developer.

When we first learned how to make network requests, we were introduced to the concept of HTTP (Hypertext Transfer Protocol) methods. One of the more common methods that people tend to be familiar with is GET, a request to a server to return a specific resource. So when you enter a URL address into a browser, it is likely translating your address into an HTTP GET request:

GET /index.html HTTP/1.1

The server then responds with a message and potentially the data that you asked for:

HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Content-Type: text/html; charset=UTF-8
Content-Encoding: UTF-8
Content-Length: 138
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Server: Apache/ (Unix) (Red-Hat/Linux)
ETag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Connection: close

<title>An Example Page</title>
Hello World, this is a very simple HTML document.

Aside from GET, when you make an HTTP request, it can be formed with one of the following common methods:

A request for data from the server.
A request to write to the server.
A request to modify an existing file on the server.
A request to delete a specific file on the server.

The server then responds with a header that represents the status of the request, the way in which the request is formatted, and various other data related to the state of the response body being returned, assuming the request is successful.

From the standpoint of a browser, the page above is rendered based on the response of a GET request to From the standpoint of an iOS Developer, my experience has been handling the response bodies of these requests by parsing them into JSON objects. In my most recent project, these have been GET requests from the Foursquare API to fetch venue data that meet specified search criteria. I can then use the response data to fill a map with points of interest that a user can then select to generate a walking path (Walkmore iOS App).

Applying that to a real world example, we can think about the process of uploading a photo to Facebook and having it appear on your friends feed. In the Facebook app, you click to create a post. You are presented with a graphical interface that lets you select the photo and, when finished, it will likely make a POST request to the Facebook server. If the request is successful, the photo is now stored on Facebook’s server in a place that is associated with your account. When your friends open the Facebook app on their phone, it makes an authenticated GET request to Facebook’s server to populate the data that is presented as their news feed. The server returns available posts matching Facebook’s criteria which determine whether or not they are relevant to your friends (such as posts by you). As they scroll through this collection of posts, the app will lazily load data as needed with subsequent GET requests.

As I continue to learn about interacting with the internet as an iOS Developer, the logical follow-up is the concept of asynchrony and, according to some patterns, promises. Both aforementioned approaches will deal with making network requests while avoiding blocking the execution of your UI thread.