Building a Network Layer in iOS, Swift 5

G. Abhisek
Aug 23, 2019 · 5 min read

The network layer with respect to a mobile application development could be summed as the combination of all the components that help you create, authenticate and trigger a request and process the response.

In this blog, I will share my experiences in building a network layer from my past projects. We will discuss the reasons behind the approaches involved.

How does an API connection look like?

The device sends a request and receives a response that is the data from the server after processing the request.

API Request

An API request typically consists the following components:

a) Request type

b) Request URL

c) Headers

d) Request body

API Response

API response comprises the data that your server provides you after processing your request. The content of the responses data can be of different types that you can specify while making a request. More can be found in this link.

So without digging any further let us jump straight to configure the network layer.

Let us hop in !!

What will we discuss?

Let us look at what are the few things we would like to achieve:

  • The network layer should be modularised and each module should have a single responsibility.
  • The callee of APIs should be given back the control of the requests if in case it wants to handle any specific requirements, eg. canceling requests if needed.
  • End paths of APIs should be maintained and represented properly.
  • Looking at the network layer could give us an idea about what all are the APIs for a particular category. Eg. There might be many APIs related to customers that the application might use, like fetching all restaurants, restaurant detail fetch, etc. These all should be cumulated in a single place.
  • Every API should have the responsibility to provide its additional headers, request type, and API end path and the base path even.
  • It should be able to handle additional headers if any API has a requirement for.

For our discussion, we will be taking the help of GoogePlacesAPI. Our sample application will show a list of restaurants nearby to your current location within 200 meters.

Now let us look that how we can break down our network layer to keep it simple and testable

Common protocols, enums and model classes

API as enum cases

What could be more elegant than maintaining similar APIs under a common category. This would help us categorising our APIs. So why not do it via enum. Let us take a look at our RestaurantsAPI enum.

RestaurantAPI enum

You can find that it conforms to a protocol, APIProtocol. So what is it? Well that’s next to find out

API Protocol

This protocol composes methods which have to be implemented by any API enum as shown below. This way of implementation provides us an excellent way to add additional capabilities to our APIs.

APIProtocol

APIModelType Protocol

An actual model of ours consists of an APIProtocol type and parameters associated with it if there is any.

APIModelType

APIRequestModel

Struct which represents a complete API conforming to the APIModelType.

APIRequestModel
What the heck … !!

Well confused !! We will soon be well acquainted with all of them.

We can break the network layer to the following modules:

a) Request module

b) Configuration module

c) Sessions module

d) Helper module

Request Module

The request module comprises the request classes. Request classes are the classes that hold a similar type of APIs in them. Eg. Restaurant related APIs could be clubbed in a particular request class called the RestaurantServiceRequests classes, this class could hold the APIs for customer creation, updation, deletion, etc. Let us see how a request class looks like

RestaurantServiceRequests.swift

So what’s going on here:

We have created a RestaurantServiceRequests.swift file in which we have a structure RestaurantServiceRequests. RestaurantServiceRequests has all the APIs related to restaurants. Every APIs return a DataTask instance so that the callee could have control of the requests if they need to process anything depending on the state of the request.

Responsibilities of this module:

  • It holds request methods.
  • It holds the data parsing logic i.e converting raw response data to models.
  • Since the functions are independent of one another, you could even add more functionalities to the same eg. saving the data to the database if needed.
  • You could also create a service request class for each API if you want more segregation.

Sessions Module

Sessions module holds the singleton sessions manager. Usually we have URLSessions session manager or if we are using any third party eg. Alamofire, you have AlamofireSessionManager shared instance for that.

You could also create your own custom sessions manager if you want to have more control on the way your api sessions work. But that is out of the scope of this blog.

Configuration Module

The configuration module is the module that configures your request. It creates the request URL, adds required headers and parameters to the request. Responsibilities of this module can be cumulated as:

  • Creation of request URL by merging base path and API end path. Any additional validations and transformations to the URL can be performed here.
  • Extracting parameters from the API model and adding to the request.
  • Adding common headers or any additional headers specific to the API.
    N.B If there is any key which is common to both the common header and additional header, which one to add in priority is up to your requirement.
WebserviceConfig.swift

Helper Module

The helper module takes care of the actual triggering of the request to the sessions manager. Responsibilities of this module:

  • Calls the configuration module to create the request.
  • Authorization validation if any is needed.
  • Performs the actual triggering of the API calling the Sessions Manager.
WebserviceHelper.swift

Network Layer Schema

Network Layer schema

Sample Code

You can check the implementation of this Network Layer by downloading the sample code on GithubLink.

References

I would love to hear from you

You can reach me for any query, feedback or just want to have a discussion by the following channels:

Twitter — @G_ABHISEK

LinkedIn

Gmail: abhisekbunty94@gmail.com

Please feel free to share with your fellow developers.

Swift India

Swift Developer Community in India 🇮🇳

G. Abhisek

Written by

Software Developer(iOS), Speaker & Writer at Swift India

Swift India

Swift Developer Community in India 🇮🇳

More From Medium

More from Swift India

More from Swift India

Functional Swift: Closures { }

1.5K

More from Swift India

More from Swift India

More from Swift India

Learn about Struct in Swift

743

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade