Implementing multiple API calls (server requests) using protocols - ios

Question

I am making an app for iOS in Swift and I am trying to keep my API call logic outside of my ViewControllers. I followed this tutorial for 1 API call that I'll describe below.
I am creating a protocol 'APIControllerProtocol' that the ViewController will implement, and then I am creating an APIController class that will contain a property called 'delegate' to hold an instance of type APIControllerProtocol. The protocol is simply defined as
protocol APIControllerProtocol {
func didReceiveAPIResults(result: SwiftyJSON.JSON)
}
And the ViewController will implement the didReceiveAPIResults function to be called after the API call returns JSON data. The ViewController will contain an instance of the APIController as well to call a function which makes the call to the API.
At this point I want to have more ViewControllers perform API calls, and if I only need to make 1 API call per ViewController, I can just add another function to APIController, and I can have the new ViewController use the same protocol. However, this logic is flawed if there is a ViewController that would need to make 2 or more API calls, because
I cannot call didReceiveAPIResults in the ViewController in 2 different ways,
I don't think adding multiple 'delegate' properties to the APIController class to hold different types of protocols is the way to go.
Defining multiple functions in a protocol would mean I would have to implement all of these functions in ViewControllers that only need to make 1 API call.
My ideas to solve this problem are
Make an APIController class and APIControllerProtocol for each ViewController
Use optional functions in the APIControllerProtocol so not every ViewController would have to implement all of the functions (I don't know how this would really work)
Any other insights would be appreciated.

Answer 1

Your use of the term "API" is confusing. It sounds like what you mean is a server request, so that's what I'm going to call it.
I would suggest using a completion block/closure design rather than a protocol-based design.
Make your calls to your network request class take a completion closure, and call that completion closure once the server request is done.
You can write your network request class to maintain a list of requests and the completion closure for each pending request, and invoke the closure for each request once it completes or fails.

Answer 2

Defining multiple functions in a protocol would mean I would have to
implement all of these functions in ViewControllers that only need to
make 1 API call.
This is incorrect. Create optional functions and you probably have your answer.
#objc protocol APIControllerProtocol {
func didReceiveAPIResults(result: SwiftyJSON.JSON)
optional func someAwesomeMethod()
}
https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Protocols.html
Optional Protocol Requirements
You can define optional requirements for protocols, These requirements
do not have to be implemented by types that conform to the protocol.
Optional requirements are prefixed by the optional modifier as part of
the protocol’s definition.
An optional protocol requirement can be called with optional chaining,
to account for the possibility that the requirement was not
implemented by a type that conforms to the protocol. For information
on optional chaining, see Optional Chaining.
You check for an implementation of an optional requirement by writing
a question mark after the name of the requirement when it is called,
such as someOptionalMethod?(someArgument). Optional property
requirements, and optional method requirements that return a value,
will always return an optional value of the appropriate type when they
are accessed or called, to reflect the fact that the optional
requirement may not have been implemented.

Answer 3

The tutorial you're basing your logic on does not look ok to me. What it does, it implements a standard delegation pattern tweaked to the max. DetailsViewController has an APIViewController instance to which it assigns itself as the delegate - pretty standard. But then DetailsViewController calls methods on that APIViewController instance in order to get the delegate methods fired, which are implemented in DetailsViewController. That's too much going in circles for my taste.
A much more sensible pattern would be to create a singleton (shared instance) object which would handle your API calls and any view controller could access it. There you can implement your methods that take your parameters, one of them being a closure which could be called when your request completes passing the result to the view controller.
So in your view controller you'd call something like this:
APIController.sharedInstance.doSomethingWith(someParameter, completion: { (result) -> Void in
// Do something with the result
})
Your APIController would implement this something like this
func doSomethingWith(param: String, completion: (AnyObject) -> Void) {
// do your data fetching here...
// pass the result to the closure when the data is retrieved
completion(result)
}