IT의 중심에서

기술은 사람을 행복하게 할 때 가장 가치가 크다.

API 버전과 미디에이션

APIgee 블로그 글입니다.
오랜동안 번역을 미루어두었던 글인데 이제 꺼내봅니다.
API 비즈니스를 하다보면, 여러가지 이유로 제휴사별로 API를 중복 개발하거나 관리하는 경우가 생깁니다.
아래는 그런 경우 version을 분리하거나, API Mediation Layer를 만들라고 조언합니다.
플랫폼 설계에서 Mediation을 왜 만들고, 어떤 역할을 하는지를 잘 이해할 수 있는 아티클입니다.

서버 기반의 대용량 플랫폼을 구축해본 분들은 일상적인 개념일 수 있지만, 서버분야에 처음이신 분들께는 생소할 것 같습니다. 도움이 될까 번역해보았습니다.


mediation-1
※ 원문 : One size doesn’t fit all. : API versioning and Mediation
※ 저자 : Scott Regan, 2009.08.04

모든 것을 만족시키는 하나의솔루션은 없다.

TrueCredit.com 이 자신들의 Open API를, 서로 다른 버전과 선호도에 맞추기 위해 수천 개 ip address를 계산한 이야기는 유명하다.

만일 모든 사람을 만족시켜주는 ‘하나의 만능 API’를 가졌다고 하더라도, 코딩없이 SLA를 바꾸거나, 계약서를 전달하거나, 새로운 API 버전을 만들거나, 데이터를 변환할 필요가 생긴다.

그 이유는 다음과 같다.

  • 프로토콜의 상이성
  • REST API를 가진 SaaS 제공자들은 은행과 반드시 연동을 하게 된다.
    하지만, 은행들은 WS-Security 기반의 SOAP API 만 제공하고 있다.
    또는, SOAP을 이용하는 어떤 업체들은 개발자가 더 쉽게 일할 수 있게 REST API를 제공하고 싶어한다.
    그래서 당신은 SOAP, REST, REST/JSON 등을 서로 변환할 필요가 생긴다.

  • 수익화의 필요성
  • ‘만능 API’의 프리미엄 버전을 팔고 싶을 수 있다.
    예를 들면, 어떤 search API Provider는 BD 거래를 위해서 무료 API를 제공하고 싶어한다.
    하지만, 동시에 파트너들이 구매하려는 부가 데이터를 추가로 제공해야 하기도 한다.

  • 표준화의 필요성
  • 어떤 고객은 1개에서부터 시작해 이제는 40개 정도의 API를 제공하고 있다.
    그런데, 각 API 에 몇 개의 표준필드를 추가하고 싶어했다.
    하지만, 팀 전체 코드를 통제하지 않으면서 API의 일관성을 유지하고 싶어했다.

  • 버전의 필요성
  • API를 새로운 버전으로 업그레이드하라고 매달 이메일을 받아본 적이 있는가?
    TrueCredit 은 가능한한 API를 오래 쓰고 싶어하거나, 버전관리의 어려움을 호소하는 고객들에게 API 업그레이드를 제공하고 싶어한다.

그래서, 동일한 API를 다른 버전이나 다른 스타일로 제공하는 방법을 이해할 필요가 있다.
– API 컨텐츠나 syntax를 mediate 하거나 transform 하는 방법 말이다.

여러 고객에 대응하기 위해서 열심히 중복 API를 지원하거나, 가능한 고치지 않거나, 고객이 갈 수 있는 ‘one size fits all’ 모델을 만들어보라. 아마, 매우 고통스러울 것이다.

아니면, ‘mediation’ 기능이나 API 들끼리 통신(데이터 교환, 버전, 인증교환 등)할 수 있는 Layer를 만들어라.
이것이 TrueCredit가 과금, 로드밸런싱을 위한 API 게이트웨이나 mediation을 생각해낸 이유이다.

위와 같은 이슈들이 로드맵에 포함되어 있다면, 아래와 같은 질문을 꼭 해보아야 한다.

  • 프로토콜을 변환mediate 해야 하는가?
  • 하나 이상의 프토토콜이나 서로 다른 프로토콜을 제공해야 하는가?
    (기업고객을 위해서는 SOAP, 개발자들을 위해서는 REST나 JSON을 제공해야 하는가?)
    상이한 보안 및 인증 환경에서 작동할 필요가 있는가?
    (예를 들면 단순 HTTP 인증부터 WS-Security까지 말이다.)
    특정 프로토콜에서 Syntax Issue를 다룰 필요가 있는가? (SOAP 1.1 vs 1.2 등)
    API 버전들을 최소화하는게 중요한가?

  • 버전관리가 중요한가?
  • 얼마나 자주 API를 업그레이드해야 하는가? 고객에게 업그레이드를 요청하는 프로세스는 무엇이고, 버전 종료에 걸리는 기간은 얼마나 되는가?
    하나 이상의 API를 제공하고 있다면, API 구성 요소들을 표준화할 필요가 있는가? (header, payload 등) 다른 팀이 이일을 할 필요가 있거나, 이런 능력을 한 포인트에 넣은 것이 합리적인가?

  • payload 변환기능Transformation이 필요한가?
  • 특정 고객이나 서비스를 위해 API를 강화할 필요가 있는가?
    (더 많은 데이터를 사용하는 우수고객 대상으로 말이다.)
    어떤 고객들이나 서비스를 위해 특정 필드를 제거하거나 생략할 필요가 있는가?
    비즈니스와 디바이스, 제품사이클에 대해 이런 요청들에 얼마나 빨리 대응할 수 있는가?

mediation layer는 복잡성을 다루기 위해 매우 중요하다.
그것은 API의 비즈니스 역량을 높이기 위해 개발에 집중할 수 있게 해준다.

Advertisements

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중

정보

이 엔트리는 2013년 10월 8일에 님이 API와 기술, 번역글에 게시하였으며 , , , 태그가 지정되었습니다.

내비게이션

%d 블로거가 이것을 좋아합니다: