조이시티의 프리스타일 풋볼의 모바일 앱 개발을 위해 클라이언트 사이드에서 사용하기 위한 Web API를 개발 하게 됐다. 아무래도 사내 서비스 영역에서 웹 클라이언트(Browser) 또는 Server-To-Server를 위한 API 만을 개발 해왔기 때문에 모바일 환경에서의 통신을 위해 고려해야 될 사항은 무엇일까? 라는 생각이 필요해 보인다.

구체적인 내용보다는 먼저 스케치 단계의 생각들을 간단히 요약해보자.

클라이언트에 어떠한 형식으로 데이터를 전달 할 것인가?

Android 그리고 iOS의 네이티브 앱에서 API를 사용하기 위해서는 웹기반의 API와 마찬가지로 XML or JSON 형태로 데이터를 요청하거나 처리 하면 좋을 듯 하다.

여기에 API의 각 요청에서 공통적으로 제공하는 응답 형태가 필요해 보인다. HTTP 응답은 아래와 같이 일관적인 형태의 코드와 메시지를 전달해주는 방식을 고민해볼만 하다.

1
2
3
4
5
{
"result": <object>,
"errorCode": <integer>,
"message": <string>
}

그리고 브라우저 기반의 클라이언트를 위한 API와의 차이점이라면 모바일 디바이스 정보를 수집하는 일도 중요해 보인다. 아래와 같이 말이다.

  • 모바일 기기의 OS (Android, iOS, Windows Mobile)
  • OS의 Version
  • 기기의 고유 식별번호

이를 위해서 HTTP 스펙에서 기본적으로 제공하는 Header 값을 참조할 만하다.

사용자 인증 및 API 요청에 대한 권한에 대한 체크는 어떻게 할 것 인가?

웹 기반에서는 보통 Cookie 또는 Session을 활용해 도메인 단위로 사용자의 정보를 암&복호화해 인증을 하고 각 요청에 권한 체크를 하였다. 하지만 이렇게 구현된 인증 방식은 웹 기반의 환경에서만 국한되기 쉽기 때문에 이러한 방식보다는 OAuth 스펙의 인증 방식을 고려해볼만 하다.

인증 서버 구현에 비용이 많이 드는 OAuth 1.0a 보다는 SSL을 이용한 OAuth 2.0 기반의 인증 방식을 이용해 클라이언트에 accessTokenrefreshToken 를 발급하고 이러한 정보를 이용해 API 요청에 대한 권한을 체크하는 방향이 좋아보인다. HTTP 요청의 헤더 값에 아래와 같이 인증을 위한 토큰 정보를 첨부하는 것을 예시로 들 수 있다.

1
-H "Authorization: <accessToken>"

인증 및 API 요청에 따른 다양한 상황에서 발생되는 예외는 어떻게 처리할 것이고, 어떠한 방식으로 효율적으로 예외 또는 에러에 대한 정보를 전달 할 것인가?

기본적으로 Web API는 예상치 못한 요청으로 인해 애플리케이션 단위에서 런타임 오류가 발생할 경우가 있는데 이 경우에는 기존의 개발 방식을 재사용해도 문제는 없어 보인다. 아래와 같이 말이다.

1
2
3
4
{
"errorCode": 1001,
"message": "Invalid requests"
}

추가적으로 각 API를 구현하기 위한 Controller에서 각각의 예외 처리를 하기는 보다는 공통적으로 발생되는 예외에 대한 처리를 하는 클래스를 구현하는 것이 좋겠다. 런타임에서 발생할 수 있는 예외케이스를 통해 예외 클래스를 정의하고 애플리케이션 단위에서 예외처리를 하는 방식말이다.

단위 테스트는 어떻게 할것 인가?

네이티브 클라이언트의 사용자 입장에서의 단위 테스트 필요하다고 생각한다. 물론 여기에서 테스트 범위는 클라이언트에서의 API 요청에 국한된다. 가장 좋은 방법은 역시 API를 테스트하기 위한 안드로이드 샘플 애플리케이션을 구현하는 것이다.

이 과정에서 Android 환경에서의 테스트의 복잡성에 대해 이해하고 테스트 범위를 분리해 나아가는 것이 중요해보인다. Android의 Dalvik VM 을 통해 테스트 환경이 구성되어야 된다는 점, 이러한 OS 환경에 맞물려 단위 테스트 했을시 속도가 느리다는 단점이 있다. 단위 테스트는 즉각 즉각 빨리 확인하는게 최고! 그래서 앞으로 더 고민해봐야 될 부분 인 것 같다.

마치며

일단 지금은 머리속에서 생각나는 것을 두서 없이 정리해 보았고, API 설계하고 구현하면서 생산되는 문서를 바탕으로 기회가 되면 다시한번 구현된 내용을 정리해봤으면 좋겠다.