🍒서버 응답 Cherry Pick!🍒 (OkHttp Interceptor)

대다수의 규모가 있는 어플리케이션들은 자체 서버를 운영하며 REST API를 기반으로 둔 서버 통신들은 데이터를 JSON의 형태로 주고받습니다. 안드로이드의 개발자라면 이런 서버들과 REST API를 이용한 통신을 하기 위해서 Retrofit, OkHttp, Gson과 같은 라이브러리를 한 번쯤 들어보았거나 사용해보았을 것입니다.

이 포스팅은 이러한 통신 코드를 작성하는 상황에서 서버의 JSON 응답 중, OkHttp의 Interceptor를 이용하여 우리가 원하는 데이터 부분만 뽑아서 별도의 파싱 없이 바로 사용할 수 있는 코드를 짤 수 있는 방법에 대해서 다룹니다. 이 방법을 사용하면 Retrofit 인터페이스를 정의하는 과정과 사용하는 과정이 매우 편리해집니다!😀

Problem : Boilerplate code😫

다음과 같은 서버의 응답을 생각해보겠습니다. 서버에서 정상적인 응답이 성공한 상황입니다.

{
    "status": 200,
    "success": true,
    "message": "펀딩 정보 조회 성공",
    "data": [
        {
            "funding_idx": 95,
            "user_idx": 12,
            "store_idx": 1,
            "funding_money": 2400,
            "reward_percent": 0,
            "funding_time": "2019-12-30T04:44:55.000Z",
            "reward_money": 0
        },
        {
            "funding_idx": 87,
            "user_idx": 12,
            "store_idx": 6,
            "funding_money": 2400,
            "reward_percent": 0,
            "funding_time": "2019-12-29T11:57:39.000Z",
            "reward_money": 0
        },
        ....
    ]
}

다음은 서버에서 정상적인 응답이 실패한 경우입니다.

{
    "status": 400,
    "success": false,
    "message": "해당하지 않는 userIdx값입니다."
}

우리가 이러한 서버의 응답을 Retrofit의 GsonConverterFactory를 이용해서 받으려면 어떻게 해야 할까요? 이상적인 상황이라면 우리는 보통 data에 해당하는 객체들의 리스트만 받아와서 UI에 보여주고 싶을 것입니다. 그러면 다음과 같은 코틀린의 데이터 클래스를 먼저 정의합니다. 이를 Funding이라는 데이터 클래스로 정의했습니다.

Funding 데이터 클래스

그리고 사실상 필요 없지만 status, success, message과 응답이 실패할 시에 data가 오지 않으므로 data를 nullable로 정의한 ResponseWrapper 데이터 클래스를 하나 정의합니다. 이는 서버의 응답이 모두 위와 같은 형식이기 때문에 모든 요청의 응답에 계속 쓰이게 됩니다.

ResponseWrapper 데이터 클래스

그러면 다음과 같이 Retrofit 인터페이스를 만들 수 있습니다.

@GET("mypage/fundlist")
fun listFundingHistories() : Call<ResponseWrapper<List<Funding>>>

그리고 다음과 같이 코드상에서 쓸 수 있습니다.

Dirty Response Wrap!

서버랑 통신 한번 하겠다는데 골 때리는 코드가 아닐 수 없습니다😫. 실제로 조금 과장하기 위해서 코드를 위와 같이 만들었지만, 완전히 비합리적인 코드는 아닙니다. 여기서 주석으로 숫자를 달아둔 네트워크 요청의 실패 케이스에 대해서 살펴보겠습니다.

1. 서버와 통신이 아예 실패한 상황입니다. 서버가 닫혀있을 수도 있고, 404 Not Found 에러가 났을 수도 있고 TimeOut 일 수도 있습니다.
2. Response에서 Code가 200 이상 300미만이 아닌 경우입니다. REST API에서 논리적으로 성공 응답으로 간주되는 Code의 범주 인지로 응답이 성공했는지를 검사합니다.
3. 서버 개발자가 개발한 로직상에서 실패했을 때입니다. 보통 2번이 성공했는데 3번이 실패하는 경우는 서버 개발자의 실수가 아니라면 드뭅니다.
4. 서버에서도 성공했는데 데이터가 없는 경우입니다. 보통 응답에서는 데이터가 필요하지만 응답 데이터가 필요 없이 코드만 200~300으로 오는 응답도 종종 있기 때문에 선택적인 검사 사항입니다. 보통 2번이 성공했을 때 4번이 실패하는 경우는 드뭅니다.

여기서 1,2번은 Retrofit 라이브러리에서 결정해주는 실패 상황이고, 3,4번은 서버 프로토콜이 status, success, message 그리고 data로 한번 싸여있기 때문에 어쩔 수 없이 한 번 더 검사해야 하는 실패 상황입니다. 물론 이를 RxJava나 Kotlin Coroutine 그리고 ResponseWrapper에 대한 확장 함수를 이용하면 좀 더 간편하게 응답을 처리할 수 있겠지만, 어찌 되었든 우리가 서버의 규격에 맞춰진 응답 때문에 ResponseWrapper란 녀석을 한 꺼풀 벗겨내야 한다는 것은 다름없습니다.

저는 보통 서버 개발자가 위와 같이 응답을 보내주는 것을 선호하지 않습니다. status와 success라는 응답 값은 응답의 코드로 판단을하면 되는 일이고 message는 간단한 에러 메세지를 사용자에게 띄우는 데 당장은 유용하겠지만, 앱이 확장되고 여러 언어를 지원하게 되는 순간 쓸모없는 혹덩어리가 될 뿐입니다. 조금이지만 트래픽도 더 발생할 것이고 서버 개발자보단 클라이언트 개발자가 힘들어지는 상황이 발생합니다. 단편적인 예로 Github의 API도 응답의 Body엔 데이터만 담아서 보내주는 형식으로 이루어져 있습니다.

Solution : OkHttp Custom Interceptor😀

하지만 우리는 항상 개발의 초기 단계부터 관여할 수 있지 않고, 이미 개발된 서버에 맞춰서 안드로이드 어플리케이션을 개발해야 할 수도 있습니다. 이럴 때 우리는 OkHttp의 Interceptor를 이용해서 Retrofit을 이용한 서버 요청과 응답을 중간에서 가로채 원하는 값을 끼워서 요청하거나 응답을 원하는 형태로 조금 변형할 수 있습니다.

Retrofit은 내부적으로 OkHttp라는 Http 통신 라이브러리를 사용하고 있습니다. 다음 그림은 OkHttp에서 Interceptor의 개념이 무엇인지 단편적으로 설명해줍니다.

윗부분이 우리의 어플리케이션, 아랫부분이 서버라고 볼 수 있습니다. 그냥 Interceptor는 어플리케이션 내에서 OkHttp 코어 사이에서 요청/응답을 가로채는 역할을 하고, NetworkInterceptor는 실제 통신에서 서버와 OkHttp 코어 사이에서 요청/응답을 가로채는 역할을 합니다.

결론적으로 Interceptor를 장착해서 어떻게 Retrofit 객체를 얻어냈는지 코드를 살펴보겠습니다.

private val client = OkHttpClient.Builder()
    .addNetworkInterceptor(commonNetworkInterceptor)
    .build()

private val retrofit = Retrofit.Builder()
    .baseUrl(BASE_URL)
    .client(client)
    .addConverterFactory(GsonConverterFactory.create())
    .build()

Retrofit.Builder를 이용하여 Retrofit 객체를 만들 때, 그냥 만든 것이 아니라 OkHttpClient 객체를 .clinet() 메서드로 탑재해서 생성해주었습니다. 그리고 OkHttpClient 객체는 addNetworkInterceptor 메서드를 이용해 어떤 Interceptor 객체를 전달해서 생성해주었습니다.

commonNetworkInterceptor 객체는 다음과 같이 생성됩니다.

private val commonNetworkInterceptor = object : Interceptor {
    override fun intercept(chain: Interceptor.Chain): Response {
        .......
    }
}

Interceptor라는 인터페이스를 구현해서 intercept라는 메서드를 오버라이딩해주기만 하면 됩니다. 이제 이 안에서 무슨 일이 일어나는지 차근차근 살펴보겠습니다.

/**
 * 1) Common Header with API Access Token
 */
val newRequest = chain.request().newBuilder()
    .addHeader("token", SPUtil.accessToken).build()

1. 공통 헤더 장착(선택) : 우선, 우리는 응답으로 온 chain 객체를 이용해서 공통적인 헤더를 달아줄 수 있습니다. 이는 응답을 파싱하는 것과는 관련없지만, 서버에 항상 공통적인 Access Token을 Header에 달아줄 때 유용합니다. 즉, Retrofit API 인터페이스를 정의할 때, @Header어노테이션을 달아줄 필요가 없어집니다.

/**
 * 2) General Response from Server (Unwrapping data)
 */
val response = chain.proceed(newRequest)

2. 서버로부터 응답받기 : chain의 proceed 메서드를 이용하면 서버로 통신을 하고 응답을 받아올 수 있게 됩니다. return 값으로 받은 response 객체가 바로 그 응답을 의미하는 객체입니다.

/**
 * 3) Parse body to json
 */
val rawJson = response.body?.string() ?: "{}"

3. 응답의 body를 JSON 문자열로 만들기: body를 toString() 메서드를 이용해서 일반 문자열로 변환했습니다.

/**
 * 4) Wrap body with gson
 */
val type = object : TypeToken<ResponseWrapper<*>>() {}.type
val res = try {
    val r = gson.fromJson<ResponseWrapper<*>>(rawJson, type) ?: throw JsonSyntaxException("Parse Fail")

    if(!r.success)
        ResponseWrapper<Any>(-999, false, "Server Logic Fail : ${r.message}", null) //1
    else
        r

} catch (e: JsonSyntaxException) {
    ResponseWrapper<Any>(-999, false, "json parsing fail : $e", null) //2
} catch (t: Throwable) {
    ResponseWrapper<Any>(-999, false, "unknown error : $t", null)   //3
} 

4. JSON 문자열을 ResponseWrapper 형식의 객체로 Gson을 이용해서 변환하기 : Gson은 JSON 문자열을 POJO(Plain-Old-Java-Object)나 코틀린 데이터 클래스로 쉽게 변환할 수 있게 도와주는 라이브러리입니다. fromJson<T>(String, Type) 메서드를 이용하면 우리가 갖고 있는 JSON 문자열 객체를 ResponseWrapper 객체로 바꿀 수 있습니다. 이 과정에서 또 3 가지의 문제 상황을 정의할 수 있습니다. 주석으로 처리해둔 숫자를 보면,

1- JSON 문자열이 우리의 ResponseWrapper 객체로 탈바꿈은 성공했지만, success 필드가 false라서 서버단에서 정상적인 요청이 실패한 경우입니다.

2- 아예 ResponseWrapper로 탈바꿈도 실패한 경우입니다.

3- 알수없는 에러가 발생한 경우입니다.

공통적으로 에러가 발생하든 말든 ResponseWrapper라는 객체로 코틀린 문법을 이용해서 만들었습니다. 이렇게 만든 이유는 다음 단계에서 볼 수 있습니다. res라는 객체에 ResponseWrapper 객체를 갖고 있게 되었습니다.

/**
 * 5) get data json from data
 */
val dataJson = gson.toJson(res.data)

5. 원하는 데이터를 JSON 문자열로 변환 : 이제 res 객체에서 데이터 객체를 다시 JSON 문자열로 Gson의 toJson 메서드를 이용해서 만듭니다.

/**
 * 6) return unwrapped response with body
 */
return response.newBuilder()
    .message(res.message)
    .body(dataJson.toResponseBody())
    .build()

6. 기존 응답에 Message와 Body만 교체해서 응답 전달 : 기존 갖고 있던 응답인 response 객체에 newBuilder() 메서드를 이용해서 응답을 복사하고, message엔 준비해둔 message(성공일 땐 서버에서의 message 그대로, 실패일 땐 과정 4의 에러 메세지)를, data엔 우리의 데이터를 의미하는 JSON 문자열을 RequestBody 객체로 변환하여 넣어줍니다.

다음은 Interceptor 전체 코드입니다.

Result🍒

우리의 코드가 어떻게 변화되었는지 살펴보겠습니다.

우선 Retrofit의 API Interface의 메서드입니다. ResponseWrapper가 중간에서 모습을 감추었습니다.

without ResponseWrapper!

그리고 아래와 같이 Network 요청 코드를 짤 수 있게 되었습니다.

without ResponseWrapper logic check!

여전히 네트워크 통신 코드가 깔끔하진 않지만 그럭저럭 사용해질만해졌습니다.

우리가 원하는 데이터 : [Funding(nickname=null, fundingIdx=167, userIdx=113, storeIdx=30, fundingMoney=4500, rewardPercent=0, fundingTime=2020-01-03T15:22:02.000Z, rewardMoney=9000)]

네트워크 요청도 깔끔하게 성공했습니다.

그리고 위와 같이 Interceptor를 장착하는 경우,

{
    "status": 200,
    "success": true,
    "message": "사용 가능한 닉네임입니다."
}

위와 같이 data가 없는 응답도 자동으로 Code를 기반으로 성공으로 처리해줍니다.

Bonus : Coroutine❤️

최근 프로젝트에서 사용한 Coroutine은 위와 같은 코드를 필요 없게 해줍니다. Retrofit 2.6.0부터 suspend 함수를 이용한 코루틴 응답 지원이 생겼는데, 다음과 같은 코드를 작성할 수 있게 합니다.

@GET("mypage/fundlist")
suspend fun getMyFundingHistories() : List<Funding>

위와 같이 Call도 없이 suspend 함수로 API Interface 메서드를 정의하고,

lifecycleScope.launchWhenCreated {
    kotlin.runCatching {
        NetworkClient.fundingService.listFundingHistories()
    }.onSuccess {
        Timber.e("데이터 : $it")
    }.onFailure {
        Timber.e(it)
    }
}

Structured Concurrency의 CoroutineScope를 이용해 원하는 네트워크 통신을 간결하게 가능하게 하고, 액티비티가 파괴될 때 자동으로 통신이 취소되도록 만들어줍니다.

Conclusion✔️

여기까지 해서 OkHttp의 Interceptor를 이용해 서버의 JSON 응답 중, 우리가 원하는 데이터 부분만 뽑아서 별도의 파싱 없이 바로 사용할 수 있는 코드를 짤 수 있는 방법에 대해서 알아보아습니다.

Retrofit과 Gson을 공부하면 공부하는 만큼 Enum을 요청/응답에 사용하고 네트워크 통신의 여러 상황에 대해 깊이 이해하고 다루는 법에 능숙해지게 됩니다. 피드백은 언제나 환영입니다.

• Github
• Website
• Medium Blog, Dev Blog, Naver Blog
• Contact: mym0404@gmail.com