In this series, you build a modern networking layer for a Swift application using Foundation's URLSession API. We cover a range of topics, basic and more advanced, from making a simple GET request to signing requests with an access token. We make use of generics and protocol-oriented programming to create a networking layer that is flexible, testable, and easy to extend.

We start this series by making a simple GET request to the mock API to fetch the list of episodes. We won't be using a third party library. One of the goals of this series is to show you how to build a modern networking layer that relies on Foundation's URLSession API. It is simpler than you might think.

Handling errors is one of the less enjoyable aspects of software development, but it is an important one. You don't want to show the user a cryptic error message when something goes wrong, or worse, no error message. There is no clear-cut recipe you can follow. Every project is different. The good news is that error handling is built into Swift and the Combine framework. Let me show you how we can improve the code we wrote in the previous episode.

Even though there is nothing inherently wrong with a view model performing network requests, it isn't an approach I recommend. Moving the networking logic out of the view model has a number of benefits. It reduces code duplication, facilitates unit testing, and improves the maintainability of the project to name a few.

Because the application will interface with a number of endpoints of the mock API, we need to make sure the API client is easy to extend. The more we can reduce code duplication, the easier it is to extend and maintain the API client. In this episode, I show you how to use generics to make the API client extensible and easy to maintain.

The user needs to be signed in to watch a video so the next feature we implement is the ability for the user to sign in with their email and password. This episode illustrates how a proper foundation can save time and reduce complexity. The improvements we made in the previous episode simplify the changes we need to make in this and the next episodes.

Earlier in this series, we declared the computed message property in the APIError enum. While that seemed like a good idea at that time, the previous episode showed that we need a solution that is more flexible. The APIError enum doesn't have the context it needs to define a human-readable message for each of its cases.

In this and the next episodes, we add the ability for the user to watch an episode. For that to work, the application needs to fetch the video for the episode from the mock API. Fetching a video is similar to fetching the list of episodes. The difference is that the user needs to be signed in to fetch a video because a video is a protected resource. The request to the /videos/:id endpoint needs to include an Authorization header. The value of the Authorization header is the access token the application receives after successfully signing in.

In the previous episode, we extended the API client with the ability to fetch the video for an episode. Because videos are protected resources, the request includes an Authorization header with an access token as its value. The solution we implemented works, but it is tedious to pass the access token to the API client and the object invoking the video(id:accessToken:) method shouldn't need to deal with access tokens. That is a responsibility of the API client.

The video view model is no longer required to pass an access token to the API client if it requests the video of an episode. That is a welcome improvement. The API client passes an access token to an APIEndpoint object and it is the APIEndpoint object that decides when it is appropriate to add an Authorization header to a request. The changes we made in the previous episode improved the networking layer we are building.

At this point, you should have a good understanding of the networking layer we are building. Even though we have written quite a bit of code, the networking layer we built isn't complex. We simply combined a number of common patterns and techniques to create a solution that is easy to use and extend. Later in this series, I show you that it is also easy to test.

In the previous episode, you learned about CRUD operations and we applied this to video progress. We added the ability to fetch the progress for a video, the R in CRUD. In this episode, we cover creating and updating video progress, the C and U in CRUD.

In the previous episodes, we added support for fetching, creating, and updating video progress. In this episode, you learn how to delete the progress for a video, the D in CRUD. Deleting the progress for a video is a bit special because the body of the response is empty. Let me show you what changes we need to make to add support for deleting the progress for a video.

The networking layer we are building is nearing completion. We added support for most endpoints of the Cocoacasts API and, later in this series, we add support for refreshing an access token using a refresh token. In the next few episodes, we focus on unit testing the networking layer.

Even though the unit test we wrote in the previous episode passes, we quickly discovered that it gives us a false sense of confidence. The unit test passes because it is executed synchronously. To unit test the networking layer, we need to replace the synchronous unit test with an asynchronous unit test. Let me show you how that works.

To create a robust test suite, we need to be in control of the environment the test suite runs in. That includes being in control of the requests the application sends to the Cocoacasts API. We don't want the application to hit the Cocoacasts API when the test suite is run. In this episode, I show you how to stub the Cocoacasts API using the OHHTTPStubs library.

We can drastically improve the unit tests we wrote in the previous episodes. Even though the unit tests pass without issues, string literals and code duplication are subtle hints that we should take another look at the unit tests we wrote. At the end of this episode, we have a framework in place that we can use for the remaining unit tests of the APIClient class.

Are the unit tests we wrote for the /api/v1/episodes endpoint sufficient? How many unit tests should we write? These are some of the questions we answer in this episode. Developers often struggle with unit testing because they aren't sure when enough is enough. As a developer, you want a simple, straightforward answer. The good news is that code coverage can provide that answer.

Code coverage is a very helpful tool to detect gaps in a test suite. In the previous episode, we enabled code coverage to learn how to write better unit tests for the APIClient class. The coverage report shows that the episodes() method is fully covered. It also reveals that the private request(_:) method lacks coverage. Even though the request(_:) method is private to the APIClient class, we can write unit tests to indirectly test it and increase coverage of the APIClient class. That is the focus of this episode.

Step by step we are increasing the code coverage of the APIClient class. In the previous episode, you learned how to use the APIs the APIClient class exposes to unit test its private methods. Remember that the goal isn't to unit test the private methods of the APIClient class. The goal is to increase the code coverage of the APIClient class. We have a few more unit tests to write.

One of the key benefits of a robust test suite is its ability to quickly and easily test scenarios that are uncommon or hard to reproduce. In this and the next episode, we write unit tests for several scenarios that are difficult to test manually. Manual testing has value, but it is time-consuming and it can be tedious to test edge cases.

Unit tests are very useful for testing edge cases. We explored that in the previous episode. Because bugs sometimes hide in edge cases, unit tests can help you track down hard to find bugs. This is only true if the unit tests you write are sound and cover your code.

You learned in the previous episode that it is fine to ignore some of the gaps Xcode finds in your test suite. Even though the goal isn't to fill every gap, we need to write a few more unit tests for the APIClient class.