前言：在Swift慢慢趋向于稳定且高效的时候，OC也随着时间一点点的消逝，曾经的诸多OC框架也都投向了Swift的怀抱，而Swift对于框架的提升也逐渐的展露头脚。
Alamofire作为AFNetworking的升级版，在网络请求的框架中有着非常众多的使用者，所以今天就来学习Alamofire框架中的response流程和常见的多表单上传。
response流程
response在Alamofire中扮演了什么角色？
response直译过来是反应、响应的。在普通网络请求中，我们是通过闭包或者代理方法来获得数据请求请求的，这里来看一段普通请求的代码。
这是一段最简单的请求，没有头文件的设置。在闭包中返回了data，response，error三个参数。那这里的response是什么呢？
这里通过打印可以看到NSHTTPURLResponse的类，其实主体就是两个字典，而NSHTTPURLResponse是继承自NSURLResponse的类，属性是来自于NSURLResponse。
response在这里是作为保存Url、请求的状态和请求的头信息存在的，那Alamofire是否是同样的作用呢？
追溯源码开始
这里直接创建了response，是一个DataResponse，那这个DataResponse是不是在闭包中获取到的呢，暂时还不得而知。这里先来看一下DataResponse是什么。
这是一个保存信息的结构体。什么方法也没有，声明了一堆的属性。回头看创建的response，此时是保存信息。
保存的是什么信息呢，这里self.request，self.response，self.data，self.metrics，以及result都是什么呢？这里的self 指向了DataRequest，同样来到DataRequest中
DataRequest类中只有一个data，来自于mutableData，其他的属性呢？看继承的关系，只能去DataRequest的父类中去寻找。在Request类中找到了其他的的属性。数据太多，这里就不截图了。可以看到一点的是，不管是data还是其他的属性都是在这里声明的。
看到这里似乎有一点明白了，response是一个响应的存储类，保存了我们的url，返回的data，以及error等属性。
再接着向下走
-> self.eventMonitor?.request(self, didParseResponse: response)
肯定是看最后一个request的方法
这个时候肯定是需要了解清楚这个eventMonitor是什么
源码中很清晰，这里是一个协议，定义了很多的方法。只需要找到是谁实现的这个协议就清楚了request方法究竟做了什么。
再次跳转，可以看到这个eventMonitor 被添加进入了一个monitors的数组中，这下就明白了，这个request的方法是监控回调的。
这里很清楚的看到并没有使用session的闭包请求，那么请求的回调一定是发生在代理中的。
最开始的ruqest方法已经开始了请求，那么就需要在URLSessionDataDelegate实现的代理中找到回调的方法
在这里我们就将请求到的数据写入了对应的response中去了。
当然在这里还没有结束-> self.responseSerializerDidComplete 这一句就是将闭包追加到请求的状态中。
当请求成功的时候将请求的状态修改为isFinished，然后调用对应外界的回调闭包，将请求的数据及请求的状态以及请求的参数打包整理好的response，通过闭包回调出去。
总结一下：Alamofire 采用了将请求和参数以及回调的闭包封装为成为一个新的DataResponse，然后通过监听URLSessionDataDelegate代理中回调的方法，获取到请求成功或失败的数据，再将其添加到DataResponse中，最后通过保存的闭包将其返回，完成一个闭包返回所有数据的功能。
