Status Code에 따른 네트워크 처리

저는 현재 SeSAC iOS 앱 개발자 데뷔과정 PLUS를 수강하고 있습니다.

Light Service Level Project을 진행하던 중 겪은 Status Code에 따른 네트워크 처리를 공유하기 위해 글을 적어봅니닷

 

LSLP(Light Service Level Project)의 테스트 서버는 로그인 후

1분 경과 시: AccessToken 만료

5분 경과 시: RefreshToken 만료

 

자동 로그인에 필요한 AccessToken과 RefreshToken을 테스트 서버는 짧은 시간안에 만료시키고 있습니다.

 

앱 최초 실행 시

로그인 화면 실행

회원가입 버튼 클릭 후

이메일, 비밀번호, 닉네임 기입 -> 회원가입 성공 -> 로그인 성공

 

앱 재실행

앱을 삭제하지 않았고 UserDefaults에 Token들을 저장하고 있음

• 미접속 1분 이전에 앱 재진입
  • 409 에러를 반환 (409 에러는 AccessToken이 유효할 때의 코드)
• 미접속 1분 이후에 앱 재진입
  • AccessToken은 만료되고 refreshToken은 만료되지 않았으므로 statusCode는 200으로 떨어지고 있지만 statusCode 분기처리가 제대로되지 않고 있는듯함
• 미접속 5분 이후에 앱 재진입
  • refreshToken 만료로 418 code가 떨어지지만 로그인 화면이 아닌 메인 홈화면으로 진입하는 중
  • 이 부분도 분기처리의 문제로 판단

 

초기 값이 없는 PublishRelay에서 초기 값이 존재하는 BehaviorRelay로 수정 (초기 값 nil)

let statusCode = BehaviorRelay<Int?>(value: nil)//PublishRelay<Int>()//BehaviorRelay<Int?>(value: 0)
// PublishRelay에서 BehaviorRelay로 수정 초기 값 nil

 

앱 최초 실행 시

로그인 화면 실행

회원가입 버튼 클릭 후

이메일, 비밀번호, 닉네임 기입 -> 회원가입 성공 -> 로그인 성공

앱 재실행

• 미접속 1분 이전에 앱 재진입 -> 409 code 리턴 -> 메인 홈화면 진입 성공
• 미접속 1분 이후에 앱 재진입
  • AccessToken은 만료되고 refreshToken은 살아있기에 200을 리턴하지만 아직 분기처리가 제대로 되지 못하고 있는 것 같다.
  • status가 200을 리턴하면서 추가적으로 custom error code가 0 값으로 리터되는데 이것은 API 호출에 성공하였지만 Decoding에 실패하는 경우를 대비하여 custom으로 만들어 놓은 Error이다.
• 원인
  • statusCode 200을 리턴할 때 invalidData 에러를 보내게되는데 invalidData는 decoding 부분의 문제가 발생할 시 statusCode를 0으로 리턴하라는 Custom Error 이다.
• 분석
  • decoding 부분을 확인해보았고 Netword Repository 부분도 확인해보니 AccessToken 갱신에 대한 API의 응답모델은 LoginResponse를 응답받고 있었다.
    • (뜬근 없이 LoginResponse가 나오는 이유는 응답 값이 같아 모델만 동일한 모델을 사용한 것이다.)
  • AccessToken API는 200 리턴 시 token만을 반환하는데 LoginResponse는 내부는 token, refreshToken으로 이루어져있기에 모델이 맞지 않아 invalidData 에러를 반환하는 것이었다.
  • 코드와 함께 확인해보자.

struct LoginResponse: Decodable {
    let token: String
    let refreshToken: String
}

struct AccessTokenResponse: Decodable {
    let token: String
}

• 결론
  • 로그인 시 AccessToken과 refreshToken 2개를 응답 받는 것과 AccessToken 갱신 시 AccessToken 1개만을 응답 받는 차이에서 확실하게 인지하지 못하고 응답모델을 넣어주고 있었던 것 같다.
  • Response 모델을 각각의 API에 맞게 넣어주어야하는 중요성을 다시 한 번 깨달을 수 있었다!

 

마무리

실제 서비스 수준의 프로젝트를 개발하게되면 API의 수 만해도 몇십 ~ 몇백 개의 API가 존재할텐데 API 마다 응답 모델이 상이하기에 제대로 확인하고 코드를 작성해야겠다는 생각이 들었던 문제 해결이었습니다! 오늘도 읽어주셔서 감사합니다~