[iOS] [英] Swift 中的后端 API 文件

Datetime:2016-08-23 04:13:35          Topic: Swift           Share

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





About List