[Http] API

애플리케이션 프로그래밍 인터페이스(API)란?

각 기업에서는 애플리케이션 프로그래밍 인터페이스, 즉 API를 통해 자사 애플리케이션의 데이터 및 기능을 외부 써드파티 개발자, 비즈니스 파트너, 사내 부서에 공개할 수 있습니다. 그러면 문서화된 단일 인터페이스를 통해 여러 서비스와 제품끼리 서로 통신하고 상호 데이터와 기능을 활용하는 것이 가능해집니다. 개발자는 API가 어떻게 구현되었는지를 알 필요 없습니다. 다른 제품 및 서비스와 통신하는 데 이 인터페이스를 사용하면 됩니다. API 사용이 지난 10여 년간 급격히 증가했습니다. 오늘날 가장 많이 쓰이는 웹 애플리케이션의 상당수는 API가 없다면 등장하지 못했을 것입니다.

API의 작동 방식

API는 컴퓨터나 애플리케이션의 상호 통신 방식을 설명하게끔 정의된 규칙의 모음입니다. API는 애플리케이션과 웹 서버의 사이에서 중간 계층의 역할을 하면서 시스템 간 데이터 전송을 처리합니다.

API의 작동 방식은 다음과 같습니다.

1. 클라이언트 애플리케이션에서 정보를 가져오기 위해 API 호출을 시작합니다. 이를 요청(request)이라고도 합니다. 애플리케이션에서 웹 서버로 전달되는 이 요청은 API의 URI(Uniform Resource Identifier)를 사용하여 처리합니다. 여기에는 요청 동사, 헤더, 경우에 따라서는 요청 본문도 포함됩니다.
2. API는 유효한 요청을 받으면 외부 프로그램이나 웹 서버에 호출합니다.
3. 서버가 API에 응답하면서 요청받은 정보를 보냅니다.
4. API가 원래 요청했던 애플리케이션에 데이터를 전송합니다.

데이터 전송은 현재 사용 중인 웹 서비스에 따라 달라지지만, 이러한 요청 및 응답 프로세스가 모두 API를 통해 이루어집니다. 사용자 인터페이스는 사람이 사용할 목적으로 설계되었지만, API는 컴퓨터나 애플리케이션에서 사용하도록 설계됩니다.

API는 그 본연의 기능상 보안을 제공합니다. 두 시스템 사이에서 중개자의 역할을 하면서 기능을 추상화하기 때문입니다. API 엔드포인트가 서비스 소비자인 애플리케이션과 그 서비스를 제공하는 인프라를 분리합니다. 일반적으로 API 호출 시 인증 자격 증명이 포함되어 서버에 대한 공격 위험을 줄입니다. 그리고 API 게이트웨이는 액세스를 제한하여 보안 위험을 최소화할 수 있습니다. 아울러 교환 과정에서 HTTP 헤더, 쿠키, 또는 쿼리 문자열 매개변수에 의해 한층 더 강력한 데이터 보안이 이루어집니다.

결제 처리 서비스에서 제공하는 API를 예로 들어보겠습니다. 고객은 온라인 쇼핑몰의 애플리케이션 프론트엔드에서 카드 정보를 입력할 수 있습니다. 이 결제 처리 기관은 사용자의 은행 계좌에 액세스할 필요 없습니다. API가 이 거래를 위한 고유 토큰을 생성합니다. 그리고 서버에 호출할 때 이 토큰을 포함합니다. 이렇게 더 차원 높은 보안으로 잠재적 해킹 위협을 방지합니다.

API가 필요한 이유

기존 툴을 관리하거나 새로운 툴을 설계하는 어떤 경우에도 애플리케이션 프로그래밍 인터페이스를 사용하여 그 프로세스를 간소화할 수 있습니다. API는 다음과 같은 주요 이점을 제공합니다.

• 협업 증진: 일반적인 기업에서는 대략 1,200개의 클라우드 애플리케이션을 사용하는데 (IBM 외부 링크), 그 중 상당수가 서로 연결되어 있지 않습니다. API는 이러한 플랫폼과 애플리케이션이 서로 수월하게 통신할 수 있도록 통합을 지원합니다. 이렇게 통합이 이루어진 기업에서는 워크플로우를 자동화하고 워크플레이스 협업을 활성화할 수 있습니다. API가 없다면, 많은 기업에서는 외딴 섬 같은 정보 사일로만 생겨나고, 이는 생산성 및 성능 저하로 이어질 것입니다.
• 더 수월하게 혁신: API가 제공하는 유연성 덕분에 각 기업은 새로운 비즈니스 파트너와 소통하고, 기존 시장에 새로운 서비스를 제공하며, 궁극적으로는 신규 시장에 진출하여 막대한 수익을 거두고 디지털 트랜스포메이션에 주력할 수 있습니다. 예컨대 Stripe라는 회사는 단 7줄의 코드로 된 API로 시작했습니다. 그 이후 많은 세계 유수의 기업들과 협업하고 사업 다각화를 통해 대출 및 법인 카드 상품까지 취급하면서 최근 기업 가치가 360억 달러 에 이르렀습니다(IBM 외부 링크).
• 데이터 수익화: 많은 기업에서 적어도 초기에는 API 무료 제공을 선택합니다. 그러면 해당 브랜드를 중심으로 개발자 그룹을 조성하고 잠재적 비즈니스 파트너와의 관계를 구축할 수 있기 때문입니다. 그러나 API가 귀중한 디지털 자산에 대한 액세스 권한을 부여하는 경우, 액세스를 유료화하여 수익을 창출할 수 있습니다(이른바 API 경제).  AccuWeather (IBM 외부 링크)는 다양한 API 패키지를 판매할 목적으로 셀프 서비스 개발자 포털을 열었습니다. 그리고 불과 10개월 만에 24,000여 명의 개발자를 유치하고 11,000여 개의 API 키를 판매하면서 성공적인 커뮤니티로 발전시켰습니다.
• 보안 강화: 앞서 설명한 대로 API를 통해 데이터와 서버 간의 보호를 한층 더 강화할 수 있습니다. 개발자는 토큰, 시그니처, TLS(Transport Layer Security) 암호화를 사용하고, 트래픽 관리 및 인증을 위해 API 게이트웨이를 구현하고, 효과적인 API 관리를 실천하면서 API 보안을 더욱 공고히 할 수 있습니다. 

대표적인 API의 예

API는 기업에서 보안 및 통제를 유지하면서도 리소스에 대한 액세스를 개방할 수 있게 하므로, 현대화된 비즈니스 환경에서 중요한 요소로 자리잡았습니다. 우리가 흔히 경험할 수 있는 애플리케이션 프로그래밍 인터페이스의 몇 가지 예를 소개합니다.

• 범용 로그인: 흔히 볼 수 있는 API의 예 중 하나가 Facebook, Twitter, 또는 Google 프로파일 로그인 정보를 사용하여 웹사이트에 로그인할 수 있게 하는 기능입니다. 이 편리한 기능 덕분에 어떤 웹사이트도 인기 서비스의 API를 활용하여 빠르게 사용자를 인증할 수 있습니다. 그러면 웹사이트 서비스마다, 또는 신규 가입을 위해 새 프로파일을 설정해야 하는 번거로움을 덜고 시간도 절약합니다.
• 써드파티 결제 처리: 예컨대 지금은 온라인 쇼핑몰에서 흔히 볼 수 있는 "Pay with PayPal" 기능도 API를 이용합니다. 이 기능은 사람들이 중요 데이터를 노출하거나 허가받지 않은 개인에게 액세스를 허용하는 일 없이도 온라인으로 제품 가격을 결제할 수 있게 합니다.
• 여행 예약 비교: 여행 예약 사이트에서는 수천 개 항공편 정보를 취합하여 날짜별, 목적지별로 가장 저렴한 옵션을 보여줍니다. 이러한 서비스는 애플리케이션 사용자가 이용 가능 호텔 및 항공사에 관한 최신 정보에 액세스하게 해주는 API 덕분에 가능합니다. API는 데이터 및 요청의 자율 교환을 통해 이용 가능 항공편 또는 숙소 확인에 드는 시간과 수고를 크게 줄여줍니다.
• Google Maps: 매우 보편적으로 쓰이는 우수한 API 중 하나로 Google Maps 서비스를 들 수 있습니다. 이 앱은 정적 지도나 대화형 지도를 표시하는 코어 API 외에도 다른 API 및 기능을 활용하여 사용자에게 길 안내를 하거나 관심 지역을 소개합니다. 위치 정보 및 여러 데이터 계층을 통해 이 지도의 API와 통신하면서 이동 경로를 표시하거나 배달 차량과 같은 이동 중인 항목을 추적할 수 있습니다.
• Twitter: 각 트윗에는 작성자, 고유 ID, 메시지, 게시 시점의 타임스탬프, 위치 정보 메타데이터 등 설명적 핵심 속성이 있습니다. Twitter는 공개 트윗 및 답글을 개발자가 이용할 수 있게 합니다. 그리고 개발자가 이 회사의 API를 통해 트윗을 게시하는 것도 가능합니다.

대표적인 API의 예

API는 기업에서 보안 및 통제를 유지하면서도 리소스에 대한 액세스를 개방할 수 있게 하므로, 현대화된 비즈니스 환경에서 중요한 요소로 자리잡았습니다. 우리가 흔히 경험할 수 있는 애플리케이션 프로그래밍 인터페이스의 몇 가지 예를 소개합니다.

• 범용 로그인: 흔히 볼 수 있는 API의 예 중 하나가 Facebook, Twitter, 또는 Google 프로파일 로그인 정보를 사용하여 웹사이트에 로그인할 수 있게 하는 기능입니다. 이 편리한 기능 덕분에 어떤 웹사이트도 인기 서비스의 API를 활용하여 빠르게 사용자를 인증할 수 있습니다. 그러면 웹사이트 서비스마다, 또는 신규 가입을 위해 새 프로파일을 설정해야 하는 번거로움을 덜고 시간도 절약합니다.
• 써드파티 결제 처리: 예컨대 지금은 온라인 쇼핑몰에서 흔히 볼 수 있는 "Pay with PayPal" 기능도 API를 이용합니다. 이 기능은 사람들이 중요 데이터를 노출하거나 허가받지 않은 개인에게 액세스를 허용하는 일 없이도 온라인으로 제품 가격을 결제할 수 있게 합니다.
• 여행 예약 비교: 여행 예약 사이트에서는 수천 개 항공편 정보를 취합하여 날짜별, 목적지별로 가장 저렴한 옵션을 보여줍니다. 이러한 서비스는 애플리케이션 사용자가 이용 가능 호텔 및 항공사에 관한 최신 정보에 액세스하게 해주는 API 덕분에 가능합니다. API는 데이터 및 요청의 자율 교환을 통해 이용 가능 항공편 또는 숙소 확인에 드는 시간과 수고를 크게 줄여줍니다.
• Google Maps: 매우 보편적으로 쓰이는 우수한 API 중 하나로 Google Maps 서비스를 들 수 있습니다. 이 앱은 정적 지도나 대화형 지도를 표시하는 코어 API 외에도 다른 API 및 기능을 활용하여 사용자에게 길 안내를 하거나 관심 지역을 소개합니다. 위치 정보 및 여러 데이터 계층을 통해 이 지도의 API와 통신하면서 이동 경로를 표시하거나 배달 차량과 같은 이동 중인 항목을 추적할 수 있습니다.
• Twitter: 각 트윗에는 작성자, 고유 ID, 메시지, 게시 시점의 타임스탬프, 위치 정보 메타데이터 등 설명적 핵심 속성이 있습니다. Twitter는 공개 트윗 및 답글을 개발자가 이용할 수 있게 합니다. 그리고 개발자가 이 회사의 API를 통해 트윗을 게시하는 것도 가능합니다.

API의 유형 및 API 프로토콜의 유형

API의 유형

오늘날 애플리케이션 프로그래밍 인터페이스 대부분은 웹 API로서 인터넷을 통해 애플리케이션의 데이터 및 기능을 공개합니다. 웹 API는 크게 4가지 유형으로 나눌 수 있습니다.

• 개방형 API: HTTP 프로토콜을 사용하여 액세스할 수 있는 오픈 소스 애플리케이션 프로그래밍 인터페이스입니다. 공개 API라고도 하며, API 엔드포인트 및 요청/응답 형식이 정의되어 있습니다.
• 파트너 API: 전략적 비즈니스 파트너에게, 또는 전략적 비즈니스 파트너에 의해 공개되는 애플리케이션 프로그래밍 인터페이스입니다. 일반적으로 개발자는 공개 API 개발자 포털을 통해 셀프 서비스 모드에서 이 API에 액세스할 수 있습니다. 단, 온보딩 프로세스를 마치고 로그인 자격 증명을 받아야 파트너 API에 액세스할 수 있습니다.
• 내부 API: 외부 사용자에게 계속 숨겨지는 애플리케이션 프로그래밍 인터페이스입니다. 이 비공개 API는 회사 외부인이 사용할 수 없습니다. 사내에서 여러 개발 팀 간의 커뮤니케이션 및 생산성을 높이는 데 그 목적이 있습니다.
• 복합 API: 여러 데이터/서비스 API를 조합합니다. 개발자는 이 서비스를 이용하여 한 번의 호출로 여러 엔드포인트에 액세스할 수 있습니다. 복합 API는 마이크로서비스 아키텍처에 유용합니다. 하나의 태스크를 수행하는 데 여러 소스의 정보가 필요할 수 있기 때문입니다.

API 프로토콜의 유형

 웹 API 사용이 늘어남에 따라, 허용되는 데이터 유형 및 명령어를 지정하는 정의된 규칙의 모음을 사용자에게 제공하기 위한 프로토콜이 개발되었습니다. 실제로 이러한 API 프로토콜은 표준화된 정보 교환을 촉진합니다.

• SOAP (Simple Object Access Protocol)는 XML로 구현된 API 프로토콜이며, 사용자가 SMTP 및 HTTP를 통해 데이터를 보내고 받을 수 있게 합니다. SOAP API를 사용하면, 서로 다른 환경에서 실행 중이거나 서로 다른 언어로 개발된 애플리케이션이나 소프트웨어 컴포넌트 간 정보 공유가 더욱 수월해집니다.
• XML-RPC 는 특정 XML 형식을 사용하여 데이터를 전송하는 프로토콜입니다. 이와 달리 SOAP는 전용 XML 형식을 사용합니다. XML-RPC는 SOAP보다 오래되었지만 훨씬 더 단순합니다. 그리고 최소한의 대역폭을 사용하기 때문에 상대적으로 가볍습니다.
• JSON-RPC 는 XML-RPC와 비슷한 프로토콜입니다. 둘 다 원격 프로시저 호출(RPC)입니다. 그러나 JSON-RPC는 XML 형식이 아닌 JSON을 사용하여 데이터를 전송합니다. 두 프로토콜 모두 단순합니다. 호출에 여러 개의 매개변수가 포함될 수 있으나, 기대하는 결과는 하나뿐입니다.
• REST (Representational State Transfer)는 웹 API 아키텍처 원칙의 모음입니다. 따라서 (프로토콜과 달리) 공식적인 표준이 없습니다. (RESTful API라고도 하는) REST API 가 되려면 아키텍처와 관련된 특정 제약 조건을 준수해야 합니다. SOAP 프로토콜을 사용하여 RESTful API를 빌드할 수는 있으나, 대개 이 두 표준은 경쟁 관계의 사양으로 간주됩니다.

API, 웹 서비스 및 마이크로서비스

웹 서비스 는 웹 주소를 통해 액세스할 수 있는 소프트웨어 컴포넌트입니다. 따라서 근본적으로 웹 서비스는 네트워크가 필요합니다.  웹 서비스에서 애플리케이션의 데이터 및 기능을 공개하므로, 사실상 모든 웹 서비스는 API입니다. 하지만 모든 API가 웹 서비스는 아닙니다.

원래 API는 애플리케이션에 연결된 인터페이스를 의미했습니다. 이는 JavaScript와 같은 로우레벨 프로그래밍 언어로 개발되었을 수도 있습니다. 현대의 API는 REST 원칙 및 JSON 형식을 준수합니다. 그리고 대개 HTTP를 위해 빌드되었기 때문에 개발자 친화적인 인터페이스가 되곤 합니다. 즉, 액세스하기 용이할 뿐만 아니라 Java, Ruby, Python, 기타 언어로 개발된 각종 애플리케이션에서 인식할 수 있습니다. 

API를 사용할 때는 주로 2가지 아키텍처 접근 방식을 적용합니다. 서비스 지향 아키텍처(SOA)와 마이크로서비스 아키텍처입니다. 

• SOA 는 소프트웨어 설계 스타일입니다. 즉, 기능을 분할하여 하나의 네트워크 내에서 개별 서비스처럼 제공합니다. 일반적으로 SOA는 웹 서비스를 사용하여 구현합니다. 표준 통신 프로토콜을 통해 기능 빌딩 블록에 액세스할 수 있습니다. 개발자는 이러한 서비스를 완전히 새로 빌드할 수도 있으나, 대개는 레거시 시스템의 기능을 서비스 인터페이스의 형태로 공개하는 방식으로 생성합니다.
• 마이크로서비스 아키텍처 는 애플리케이션을 더 작은 독립적 컴포넌트로 나누는 대체 아키텍처 스타일입니다. 애플리케이션을 개별 서비스의 모음으로 적용하면 더 수월하게 테스트, 유지 보수, 확장할 수 있습니다. 이 방법론이 클라우드 컴퓨팅 시대와 함께 등장하여 계속 각광받았습니다. 그 덕분에 개발자가 하나의 컴포넌트를 나머지 컴포넌트에 독립적으로 다루는 것이 가능해졌습니다.

SOA가 애플리케이션 개발의 진화 과정에서 중요한 단계였지만, 마이크로서비스 아키텍처는 확장성을 염두에 두고 개발되었습니다. 즉, 개발자와 기업은 민첩하고 유연한 방식으로, 더 세부적인 수준에서 애플리케이션을 개발, 수정, 테스트, 배치하면서 반복 주기를 단축하고 클라우드 컴퓨팅 리소스를 더 효율적으로 사용할 수 있게 되었습니다.

이러한 아키텍처 접근 방식의 의미를 더 자세히 살펴보고 싶다면 “SOA vs. 마이크로서비스: 차이점은?”을 참조하세요.

API와 클라우드 아키텍처

오늘날에는 목적에 부합하는 API를 개발하는 것이 중요합니다. 클라우드 네이티브 애플리케이션 개발에서는 API를 통해 마이크로서비스 애플리케이션 아키텍처를 연결하여 고객과 같은 외부 사용자와 데이터를 공유하는 것이 중요합니다.

마이크로서비스 아키텍처에 포함되는 서비스에서는 RESTful API와 비슷한 단일 공통 메시징 프레임워크를 사용하면서 운영 체제에서 개방형 통신을 지원합니다. 추가적인 통합 계층이나 데이터 변환 트랜잭션으로 인한 마찰은 발생하지 않습니다. 그리고 다른 서비스에 아무런 영향도 주지 않으면서 서비스나 기능을 삭제, 대체하거나 강화할 수도 있습니다. 이렇게 가볍고 동적이기 때문에 더 효과적으로 클라우드 리소스를 최적화할 수 있으며, 이는 더 우수한 API 테스트, 성능, 확장성으로 이어집니다.