Imagine that you're playing around on a new app, and it works great most of the time. While interacting with some of the features, you're greeted with a loading screen before the content eventually displays. Why do you think this happens? Why would an app respond immediately in some areas, but take a moment to load content in others. This happens because most applications store information on separate servers. This means that to display data, the app must first make a HTTP call to send and receive information from the server. Over the next few minutes, you will explore how HTTP calls are made in SWIFT. Discover what a URL session is, and learn how to use it. To create context, let's refer to the Little Lemon menu app, where customers can access information on available meals. When users open the menu section, the app requests data from the Little Lemon API, a server that responds to HTTP or HTTPS requests. On iOS, a URL loading system is used to configure and make HTTP requests. This is called networking, which is used by any modern iOS app that communicates with online servers during the app's life-cycle. Before learning more about HTTP requests in iOS, it's important to remember that while APIs can support both HTTP and HTTPS calls, it's always best to use HTTPS to ensure that the data sent to the server is secure. iOS provides a class called URLSession, which enables developers to send HTTPS requests in SWIFT. URLSession forms part of a larger group of classes that work together to make and respond to HTTPS requests. The URLSession class provides everything you need to make simple HTTPS networking requests. When you initialize a URLSession class instance, you create a session. You can think of a session as an open tab in your web browser which groups together many HTTPS requests in a particular websites you visit. In the same way, you can create multiple URLSession instances to group different HTTPS requests. Take the Little Lemon API, for example. To create a new session to communicate with the API, you call the shared property on the URLSession. By calling the shared property of the URL session, a singleton session with simple configuration is provided for you. Next, you can use the session to create URLSession task instances. This lets you fetch and return data to your application and download and upload files to the server. In short, URLSession is used to make multiple subsequent URLSession task instances. You can think of the URLSession as a factory for setting up and executing multiple URLSession task instances. There are several URLSession tasks sub-classes that you can use depending on the type of HTTPS request you'd like to make. For instance, the most common subclass for interacting with servers is URLSession data task. Data tasks request resources and return server responses as NSData objects. Other common sub-classes include URLSession upload task and URLSession download task. Upload tasks let you upload files before retrieving the server's response, while download tasks, download files directly to a directory on a disk. To retrieve menu item information from the Little Lemon API, you can use the URLSession data task subclass. This is done by creating a new instance of the task by calling a data task method on the session instance and passing a URL request and completion handler closure to the data task method. The data task method call returns a URLSession data task instance, which is retained by the session automatically until the task is finished. This means that there is no need to hold onto the constant unless the internal application logic requires that. Finally, the task is made executable by calling a resume method on the data task instance. This starts the execution of the data request to the Little Lemon API. All tasks perform their requests asynchronously, meaning that after the task is created and the resume method is called, the code will not wait until the response comes back before continuing the execution of the rest of the code that may be after. Instead, any code after the networking call will continue to get executed while the HTTP call is being made. Only after the response comes back, will the SWIFT system independently called the completion handler closure that was provided with the results. When the completion handler of the data task is executed, you can inspect the return data and take appropriate action. For instance, you can load the return data into the Little Lemon app to display menu item information. Because the completion handler closure is the last argument, instead of providing it explicitly, the method can also be called using a trailing closure. For instance, the trading closure body is placed after the function call instead of setting explicitly as in the previous example. This approach does not require you to define a completion closure as a separate argument beforehand. The trailing completion closure contains three arguments, data, which contains the response data if the request is successful. Response, which holds the details of the successful response, and error, which represents any errors that occurred during the request. In this video, you discovered how HTTPS calls are managed by URLSession objects. You learned that this works like browser tabs were multiple HTTPS calls are grouped together for each session instance. You should now be able to explain how a URLSession task is used to perform HTTPS requests and you should also be able to distinguish between three main URLSession task sub-classes namely, URLSession data task, URLSession upload task, and URLSession download task.
