I have recently started development on a completely new project and am trying to establish some new design patterns as I jump into Swift 3. One pattern that I am starting to use is Request & Response Models. That is the fancy name I came up with for Structs that document the backend API. Lets look at an example:
We have a protocol Request that specifies basically everything you want to know about making a request to an API.
- The path to append to the base URL (“auth” in this case)
- The HTTP Method (GET, POST, PUT, DELETE, etc.)
- The parameters the endpoint expects
You could extend this Protocol to require information like a specific ContentType or other HTTP Header. You could imagine adding validation rules, completion handlers, or anything else associated with a network request to this protocol.
Each of these Structs should now look like a succinct API documentation and provide some structure and type safety to your networking. You can pass these Request structs to your network client of choice. My example uses Alamofire :
We pass the AuthRequest object to Alamofire which expects a generic object that conforms to the Request protocol. It uses the properties/functions from the protocol to construct and execute a network call.
Now we have defined the structure of the request and used it to simply hit the server. We now need to handle the response. Our AuthRequest returns a small User JSON object that we need to serialize into a Swift object.
This approach isn’t very fancy, but still documents the properties of the response object. You could create a protocol to define an initializer that expects JSON, but just using simple Structs is working for me so far.
Do you see any issues with this approach? Is there a way I can use Protocols/Extensions to structure my networking code in a more effective way? Let me know! @iAmChrisTruman