Network Layer

All architecture is separate the business logic from the presentation. In most of them there something called NetworkManager. It’s just a single class (more often a singleton) that contains every single API call in the app.

it fails miserably for several reasons:

• Single responsibility: Our NetworkManager contains too many responsibilities to be considered a good practice
• Fail for testing: your code can’t be easily mocked when testing; reading raw data or checking why the code crush maybe a pain.

A different approach

Automatic asynchronous support Promise based implementation Out-of-box implementation from raw response -> your model Strong error handler

ServiceConfig is responsible to keep the network configuration data (full host address, headers…). You can create it programmatically or (strongly suggested) configuration can be read directly from your app’s Info.plist file.

Service: it’s a concrete implementation of the ServiceProtocol . It’s the core of the networking layer, created via ServiceConfig. This class is responsible to fulfil your requests;

Request & Response: both are concrete representations of RequestProtocol and ResponseProtocol ; as you may imagine they identify a single network request (with all required parameters and facilities) and a response from server.

JSONOperation & DataOperation: they are the higher level of the abstraction. You will subclass them to provide an out-of-box implementation of the “Raw Request to Model” paradigm.

Prepare schema-based environments

The last choice is what I suggest because is more robust and allows you to configure different environment using XCode’s schemas.

The Service Component

Its primary role is to abstract how a Request is fulfilled.

Service require the implementation of only one fun called execute: it must return a Promise with the response (as ResponseProtocol).

Prepare a Request

As we seen Request is a concrete subclass of RequestProtocol ; their role is to abstract how the Request is created. Each request allows you to set the following parameters:

• Endpoint: the url of the API call (ie. "/auth/login" )
• Method: the HTTP method of the request (POST, GET…)
• Fields (Optional): all parameters will be converted automatically to support url encoding
• URL Parameters (Optional): used to compose a dynamic endpoint
• Body (Optional): where you can specify the data to put in body.
• Headers (Optional): The list of Headers is composed as merge between Service ‘s current session headers and the Request headers

Parse the Response

Response is the concrete implementation of ResponseProtocol protocol; its role is to abstract the response from server.

• Type: success (2xx response from server), failure (for 4xx) or noResponse
• Request: its a reference to the Request instance that raised this Response.
• HTTP Response: contains the HTTP status code of the response
• Data: contains raw data received from server
• Metrics: contains all the benchmark data of the request

Create an Operation

You can think about Operation as the higher level of abstraction for our networking layer: it encapsulate the business logic of your API call and keep it in a self contained structure.

One important role of the Operation is to provide an out-of-box conversion of the raw/parsed (json) response from server to our application’s business models.