221205 TIL [Alamofire 사용법 - GET]

지금까지 모든 프로젝트에서 API통신을 URLSession을 통해 진행해 왔다
가장 큰 이유는 네이티브로 어떻게 작동이 되는지 모르는데 라이브러리만 떡칠한다면 분명 나중에 큰일이 생길 것이라는 생각때문에...
그렇기도 하고 크게 필요성을 느끼지 못했었다

그런데 지금 회사에서 API통신을 Alamofire로 하고 있어 이에대한 숙지가 필요해 스터디를 진행했는데 이게 왠걸... 완전 신세계다

AF가 적용된 코드

개인 프로젝트 Alamofire branch 링크

    func request<T: Decodable>(api:APIable, resultType: T.Type, completion: @escaping (Result<T, APIError>) -> Void) {
        let baseURL = api.host + api.path //URL string 만들기
        
        let request = AF.request(baseURL, method: api.method, parameters: api.params) //baseURL + httpMethod + parameters로 request만들기
        
        request.responseDecodable(of: resultType) { result in //responseDecodable을 이용해 요청과 decoding 진행하기
            guard result.error == nil else {
                completion(.failure(APIError.transportError))
                return
            }
            
            guard let response = result.response, (200...299).contains(response.statusCode) else {
                completion(.failure(APIError.responseError))
                return
            }
            
            guard let data = result.value else {
                completion(.failure(APIError.dataError))
                return
            }
            
            completion(.success(data))
        }
    }

그냥 위 코드 하나로 끝났다

baseURL만들어주기 -> 그 URL + HTTPMethod + parameters를 넘겨줘서 request 만들기
(현재 HTTPMethod와 parameter들은 APIable이라는 객체의 프로퍼티로 있음)

request에서 responseDecodable을 호출해 data를 어떤 타입으로 반환할지 of에 작성하고 result에 대한 체크를 한 뒤 completion으로 넘겨주었다

물론, 이 과정을 async/await와 결합해 사용할 수 있지만 그건 다음 시간에...

의문점

AF의 responseDecodable이라는 메서드를 사용했는데 스레드에 대한 설정을 해준 적이 없는데 지 알아서 비동기로 작동하고 뷰 업데이트도 잘 된다

1. responseDeodable 내부
   

• queue라는 매개변수를 받고 있으며 이건 기본값으로 main을 사용하고 있음
• 일단 responseDecodable내부에서는 스레드에 관련된 어떤 내용도 없어 response 내부로 들어감

2. response내부
   

• response내부에서도 별다른 작동 없이 _response메서드를 다시 호출하고 있어 _response내부로 들어감

3. _response내부
   

• 빨간 밑줄을 확인해보니 비동기적으로 처리하고 있음
• 파란밑줄은 처음부터 queue라는 이름으로 받은 매개변수인데 이는 completion을 어떤 스레드에서 실행시킬지 결정하는 매개변수였다

정리하자면...

• 최초 queue라는 매개변수로 받는 것은 최종적으로 서버로부터 얻어온 값들을 어떤 스레드에서 실행시킬지를 정하는 매개변수임
  • 보통 여기서 받아온 데이터로 UI업데이트를 하니 기본값인 .main에서 따로 건드릴 필요는 없고 혹여나 그 데이터를 추가적으로 가공해야할 일이 있다면 global큐로 매개변수를 주면 된다
• 서버로 요청하는 메서드의 내부에서 자동적으로 비동기로직으로 전환해 처리하여 따로 스레드 관리를 해 줄 필요가 없다

마무리

장점

• responseDecodable이라는 메서드를 통해 decoding까지 한번에 가능해 decode를 위한 객체나 코드를 생성할 필요가 없다
  • 기존 request메서드에서 generic으로 디코딩할 객체를 받아 범용성있게 사용가능
• URL string을 URL로 변환하지 않고 사용이 가능해 변환 과정 생략
• Alamofire자체적으로 HTTPMethod에 대한 enum이 있어 따로 생성해주지 않아도 된다
• dataTask에 대한 관리가 필요 없다

단점(이라기 보다는 개인적으로 더 보완해야할 점)

• URLSession의 작동원리를 파악하고 나서 접해서 그런지 API통신을 처음부터 alamofire로 접했다면 모르고 있었을 부분들이 너무도 많았을 것 같다
  • ex) decoding, 스레드 관리
• 네트워크가 없는 상태에서의 테스트에 대해 다시 새로 고민해 봐야한다
• dataTask를 통해 cancel 기능이 있고 AF의 request에도 cancel기능이 있는데 이게 같은 기능을 하는건지 의문이 든다 ( + 취소가 잘 된다 근데 asycn/await를 쓸 때 사용하는 dataTask는 cancel이 있기는 한데 제대로 안돼서 다른 셀에 이미지가 추가되곤 한다 왜이럴까...?)