게시일: 2024년 4월 9일
기고자: Michael Goodwin
API 또는 애플리케이션 프로그래밍 인터페이스는 소프트웨어 애플리케이션이 서로 통신하여 데이터, 특징 및 기능을 교환할 수 있도록 하는 일련의 규칙 또는 프로토콜입니다.
API는 개발자가 처음부터 개발하는 대신 다른 애플리케이션의 데이터, 서비스 및 기능을 통합할 수 있도록 하여 애플리케이션 및 소프트웨어 개발을 단순화하고 가속화합니다. 또한 API는 애플리케이션 소유자에게 조직 내 부서에서 애플리케이션 데이터 및 기능을 사용할 수 있는 간단하고 안전한 방법을 제공합니다. 또한 애플리케이션 소유자는 데이터 및 기능을 비즈니스 파트너 또는 제3자와 공유하거나 마케팅할 수 있습니다.
API를 사용하면 필요한 정보만 공유할 수 있고 다른 내부 시스템 세부 정보는 숨길 수 있으므로 시스템 보안에 도움이 됩니다. 서버 또는 디바이스는 데이터를 완전히 노출할 필요가 없으며, API를 사용하면 특정 요청과 관련된 작은 데이터 패킷을 공유할 수 있습니다.
API 문서는 개발자에게 API 및 해당 서비스 작업 방법에 대한 정보와 API에 대한 세부 정보를 제공하는 기술 지침 매뉴얼과 같습니다. 잘 설계된 문서는 사용자에게 더 나은 API 경험을 제공하고 일반적으로 더 성공적인 API를 만듭니다.
지능형 자동화를 통해 비즈니스 운영의 경쟁 우위를 확보할 수 있는 방법을 알아보세요.
FinOps 운영 가이드 등록하기
클라이언트와 서버 간의 요청 및 응답 측면에서 API 통신을 생각하는 것이 유용합니다. 요청을 제출하는 애플리케이션은 클라이언트이고 서버는 응답을 제공합니다. API는 이들 사이의 연결을 설정하는 브리지입니다.
API 작동 방식을 이해하는 간단한 방법은 일반적인 예인 제3자 결제 방식을 살펴보는 것입니다. 사용자가 전자상거래 사이트에서 제품을 구매할 때 'Paypal로 결제' 또는 다른 유형의 타사 시스템을 사용하라는 메시지가 표시될 수 있습니다. 이 기능은 API를 사용하여 연결합니다.
구매자가 결제 버튼을 클릭하면 정보를 검색하기 위한 API 호출이 전송됩니다. 이것이 바로 요청입니다. 이 요청은 API의 URI(Uniform Resource Identifier)를 통해 애플리케이션에서 웹 서버로 처리되며 요청 동사, 헤더 및 때로는 요청 본문이 포함되기도 합니다.
API는 제품 웹페이지로부터 유효한 요청을 받은 후 외부 소프트웨어 또는 웹서버, 이 경우에는 제3자 결제 시스템으로 호출합니다.
서버는 요청된 정보와 함께 API에 응답을 보냅니다.
API는 데이터를 초기 요청 애플리케이션(이 경우 제품 웹사이트)으로 전송합니다.
데이터 전송은 사용 중인 웹 서비스에 따라 다르지만 요청 및 응답은 모두 API를 통해 발생합니다. 사용자 인터페이스에는 가시성이 없으므로 API는 컴퓨터 또는 애플리케이션 내에서 데이터를 교환하며 사용자에게 원활한 연결로 나타납니다.
API는 데이터 API, 운영 체제 API, 원격 API, 웹 API 등 사용 사례별로 분류할 수 있습니다.
애플리케이션과 데이터베이스 관리 시스템을 연결하는 데 사용됩니다.
앱이 운영 체제 서비스 및 리소스를 사용하는 방법을 정의하는 데 사용됩니다.
다양한 디바이스의 애플리케이션이 상호 작용하는 방식을 정의하는 데 사용됩니다.
HTTP 프로토콜을 사용하여 인터넷을 통해 데이터 및 기능을 전송할 수 있도록 하는 데 사용됩니다.
오늘날 대부분의 API는 웹 API입니다. 웹 API는 인터넷을 통해 애플리케이션의 데이터와 기능을 노출하는 원격 API 유형(API가 프로토콜을 사용하여 외부 리소스를 조작하는 것을 의미)입니다.
웹 API의 4가지 주요 유형은 다음과 같습니다.
오픈 API는 HTTP 프로토콜로 액세스할 수 있는 오픈 소스 애플리케이션 프로그래밍 인터페이스입니다. API 엔드포인트와 요청 및 응답 형식을 정의했으며 공개 API라고도 합니다.
파트너 API 는 전략적 비즈니스 파트너를 연결합니다. 일반적으로 개발자는 공용 API 개발자 포털 을 통해 셀프 서비스 모드로 파트너 API에 액세스합니다. 하지만 파트너 API에 액세스하려면 온보딩 프로세스를 완료하고 로그인 자격 증명을 받아야 합니다.
내부 또는 비공개 API는 외부 사용자에게 숨겨진 상태로 유지됩니다. 이러한 비공개 API는 회사 외부 사용자가 사용할 수 없습니다. 대신 조직은 이를 사용하여 다양한 내부 개발 팀 간의 생산성과 커뮤니케이션을 개선합니다.
복합 API는 여러 데이터 또는 서비스 API를 결합합니다. 따라서 프로그래머는 단일 호출로 여러 엔드포인트에 액세스할 수 있습니다. 복합 API는 단일 작업을 실행하는 데 여러 소스의 정보가 필요할 수 있는 마이크로서비스 아키텍처에서 유용합니다.
API를 사용하면 기업은 보안과 제어를 유지하면서 리소스에 대한 액세스를 개방할 수 있으므로 최신 비즈니스 및 개인 애플리케이션의 중요한 요소로 자리 잡았습니다.
다음은 사용자가 자주 접하는 몇 가지 API 예시입니다.
인기 있는 API 예로는 사람들이 Facebook, X 또는 Google 프로필 로그인 세부 정보를 사용하여 웹사이트에 로그인할 수 있는 기능이 있습니다. 이 편리한 기능을 통해 모든 웹사이트는 빠른 인증을 위해 널리 사용되는 서비스 중 하나의 API를 사용할 수 있습니다. 이 기능을 사용하면 사용자가 모든 웹 애플리케이션 또는 새 멤버 자격에 대해 새 프로필을 설정하는 시간과 번거로움을 줄일 수 있습니다.
이러한 "스마트 디바이스"는 API를 통해 인터넷 지원 터치스크린 및 데이터 수집과 같은 추가 기능을 제공합니다. 예를 들어, 스마트 냉장고는 레시피 애플리케이션에 연결하거나 문자 메시지를 통해 메모를 작성하여 휴대폰으로 보낼 수 있습니다. 내부 카메라는 사용자가 어디서나 냉장고 안의 내용물을 확인할 수 있도록 다양한 애플리케이션과 연결됩니다.
여행 예약 사이트는 수천 개의 항공편을 집계하여 모든 날짜와 목적지에 대한 가장 저렴한 옵션을 보여줍니다. API는 애플리케이션 사용자에게 호텔 및 항공사의 가용성에 대한 최신 정보에 대한 액세스를 제공하여 이 서비스를 가능하게 합니다.
이 액세스는 웹 브라우저 또는 여행 예약 회사의 자체 애플리케이션을 통해 가능합니다. API는 데이터와 요청을 자율적으로 교환하여 이용 가능한 항공편이나 숙소를 확인하는 데 드는 시간과 노력을 획기적으로 줄여줍니다.
탐색 앱은 정적 또는 대화형 지도를 표시하는 핵심 API를 사용합니다. 이러한 앱은 또한 다른 API 및 기능을 사용하여 사용자에게 길찾기, 속도 제한, 관심 장소, 교통 경고 등을 제공합니다. 사용자는 이동 경로를 그리거나 배송 차량과 같은 이동 중인 항목을 추적할 때 API와 통신합니다.
소셜 미디어 회사는 API를 사용하여 다른 주체가 소셜 미디어 앱에서 제공하는 콘텐츠를 공유하고 자신의 사이트에 임베드할 수 있도록 합니다. 예를 들어, 인스타그램 API를 사용하면 기업이 웹사이트에 인스타그램 그리드를 삽입하고 사용자가 새 게시물을 추가하면 그리드가 자동으로 업데이트되도록 할 수 있습니다.
API는 서비스형 소프트웨어(SaaS) 제품 성장의 필수적인 부분입니다. CRM(고객 관계 관리 툴)과 같은 플랫폼에는 메시징, 소셜 미디어, 이메일 앱 등 기업이 이미 사용하고 있는 애플리케이션과 통합할 수 있는 여러 가지 기본 제공 API가 포함되어 있는 경우가 많습니다.
이 통합은 영업 및 마케팅 작업을 위해 애플리케이션 간에 전환하는 데 소요되는 시간을 크게 줄여줍니다. 또한 서로 다른 애플리케이션을 사용하는 부서 간에 존재할 수 있는 데이터 사일로를 줄이거나 방지하는 데 도움이 됩니다.
일반적으로, API는 Javascript와 같은 하위 프로그래밍 언어로 만든 애플리케이션에 연결된 인터페이스를 의미했습니다. 그러나 최신 API는 아키텍처와 데이터 형식 사용이 다릅니다. 주로 HTTP용으로 구축되므로 Java, Ruby, Python 및 기타 여러 언어로 작성된 애플리케이션에서 쉽게 액세스할 수 있고 널리 이해할 수 있는 개발자 친화적인 인터페이스를 제공합니다.
웹 API의 사용이 증가함에 따라 특정 프로토콜, 스타일, 표준 및 언어의 개발 및 사용으로 이어졌습니다. 이러한 구조는 사용자에게 허용되는 데이터 유형, 명령 및 구문을 생성하는 정의된 규칙 또는 API 사양 집합을 제공합니다. 이러한 API 프로토콜은 사실상 표준화된 정보 교환을 촉진합니다.
SOAP는 끝점에서 SMTP(Simple Mail Transfer Protocol) 및 HTTP(Hypertext Transfer Protocol)를 비롯한 다양한 통신 프로토콜을 통해 데이터를 보내고 받을 수 있도록 하는 간단한 XML 기반 메시징 프로토콜 사양입니다. SOAP는 독립적이므로 SOAP API가 서로 다른 환경에서 실행되거나 다른 언어로 작성된 앱 또는 소프트웨어 구성 요소 간에 정보를 공유할 수 있습니다.
RPC(원격 프로시저 호출)는 운영 체제에서 사용되는 높은 수준의 통신 패러다임을 제공하는 프로토콜입니다. RPC는 통신 프로그램 간에 메시지 데이터를 전달하기 위해 TCP/IP(Transmission Control Protocol/Internet Protocol) 또는 UDP(User Datagram Protocol)와 같은 하위 수준 전송 프로토콜이 있다고 가정합니다.
RPC는 네트워크 응용 프로그램을 지원하기 위해 특별히 설계된 논리적 클라이언트-서버 통신 시스템을 구현합니다. RPC 프로토콜을 사용하면 사용자가 프로시저가 로컬인 것처럼 원격 프로시저를 사용할 수 있습니다.1개
XML-RPC 프로토콜은 특정 XML 형식을 사용하여 데이터를 전송합니다. XML-RPC는 SOAP보다 오래되었지만 최소 대역폭을 사용한다는 점에서 더 간단하고 상대적으로 가볍습니다.
XML-RPC와 마찬가지로 JSON-RPC는 XML 대신 JSON (자바스크립트 객체 표기법) 을 사용하는 원격 프로시저 호출입니다. JSON은 파싱이 간단하고 이름/값 쌍과 정렬된 값 목록을 사용하는 간단한 데이터 교환 형식입니다. JSON은 범용 데이터 구조를 사용하므로 모든 프로그래밍 언어와 함께 사용할 수 있습니다.
gRPC는 Google에서 처음 개발한 고성능 오픈소스 RPC 프레임워크입니다. gRPC는 네트워크 프로토콜 HTTP/2 및 프로토콜 버퍼 데이터 형식을 사용하며 일반적으로 마이크로 서비스 아키텍처에서 서비스를 연결하는 데 사용됩니다.
웹소켓 API를 사용하면 클라이언트와 서버 간의 양방향 통신이 가능합니다. 이 유형의 API는 매번 통신할 때마다 새로운 연결을 설정할 필요가 없으며, 일단 연결이 설정되면 지속적인 교환이 가능합니다. 따라서 웹 소켓 API는 실시간 커뮤니케이션에 이상적입니다.
REST는 일련의 웹 API 아키텍처 원칙입니다. REST API (RESTful API라고도 함)는 특정 REST 아키텍처 제약 조건을 준수하는 API입니다. REST API는 GET, PUT, HEAD 및 DELETE와 같은 HTTP 요청을 사용하여 리소스와 상호 작용합니다. REST를 사용하면 데이터를 리소스로 사용할 수 있으며 각 리소스는 고유한 URI로 표시됩니다. 클라이언트는 해당 URI를 제공하여 리소스를 요청합니다.
REST API는 상태 비저장 API로, 요청 사이에 클라이언트 데이터를 저장하지 않습니다. SOAP 프로토콜을 사용하여 RESTful API를 빌드할 수 있지만 실무자는 일반적으로 두 표준을 경쟁 사양으로 간주합니다.
GraphQL 은 클라이언트가 API와 상호 작용하는 방법을 지정하는 오픈 소스 쿼리 언어 및 서버 측 런타임입니다.2 개 GraphQL을 사용하면 파라미터가 많은 복잡한 엔드포인트에 액세스할 필요 없이 단 몇 줄로 API 요청을 수행할 수 있습니다. 이 기능을 사용하면 API 쿼리, 특히 여러 리소스를 대상으로 하는 더 복잡하거나 구체적인 요청을 더 쉽게 생성하고 응답할 수 있습니다.
SOAP 및 REST는 API 설계에 대한 다양한 접근 방식을 나타내며 API가 다른 애플리케이션과 상호 작용하는 방법에 대한 규칙 및 표준을 설명합니다. SOAP는 프로토콜이고 REST는 아키텍처 스타일을 구성하는 제약 조건 집합입니다. 둘 다 HTTP를 사용하여 정보를 교환합니다.
REST는 가볍고 유연하며 투명하고 상대적으로 사용하기 쉽기 때문에 SOAP에 대한 더 간단한 대안으로 간주되는 경우가 많습니다. SOAP에서는 사용자가 각 작업을 완료하기 위해 REST에 필요한 것보다 더 많은 코드를 작성해야 합니다.
SOAP는 유형 검사로 인해 더욱 결정적이고 강력하며, 지지자들은 많은 개발 툴에 내장된 SOAP 지원으로 인해 SOAP가 사용하기 더 쉽다고 주장합니다.3 SOAP에는 규정 준수 기능이 내장되어 있으며 개발자는 이를 더 안전한 프로토콜로 간주하여 엄격한 데이터 무결성 요구 사항이 있는 상황에 더 적합하다고 생각하는 경우가 많습니다.
RESTful 시스템은 일반 텍스트, HTML, YAML, XML 및 JSON과 같은 다양한 형식의 메시징을 지원하지만 SOAP는 XML만 허용합니다. 각각의 강점이 있으며, 사용 사례에 따라 '올바른 선택'이 달라질 수 있습니다. 그러나 데이터 저장 및 교환을 위해 여러 형식을 지원하는 기능은 REST가 퍼블릭 API를 구축하는 데 널리 사용되는 이유 중 하나입니다.
GraphQL은 2015년 오픈 소스가 되기 전에 Facebook이 2012년에 내부적으로 개발한 쿼리 언어 및 API 런타임입니다. GraphQL과 REST는 모두 상태 비저장이며, 클라이언트/서버 모델을 사용하며 HTTP를 사용합니다. GraphQL은 REST의 몇 가지 제한 사항을 해결하여 단일 요청으로 원하는 리소스를 보다 정확하게 타기팅할 수 있는 기능을 제공합니다.
REST API는 고정된 구조를 따르며 항상 지정된 개체에 대한 전체 데이터 집합을 반환합니다. 예를 들어 요청이 여러 리소스에 걸쳐 더 복잡한 경우 클라이언트는 각 리소스에 대해 별도의 요청을 제출해야 합니다. 이러한 제한으로 인해 페치 부족 또는 과잉 문제가 발생할 수 있습니다.
여기에서 GraphQL과 REST에 대해 자세히 알아보기
REST나 GraphQL API는 본질적으로 우수하지 않습니다. 다양한 작업에 적합한 다양한 툴입니다.
REST는 일반적으로 구현하기가 더 쉬우며 엄격한 액세스 제어를 갖춘 간단하고 캐싱이 가능한 통신 프로토콜을 선호하는 경우 (예: Shopify 및 GitHub와 같은 공용 전자 상거래 사이트의 경우) 좋은 선택이 될 수 있습니다.
GraphQL API는 보다 유연하고 효율적인 데이터 가져오기를 지원하여 개발자의 시스템 성능과 사용 편의성을 향상시킬 수 있습니다. 이러한 기능 덕분에 GraphQL은 프런트엔드 요구 사항이 빠르게 변화하는 복잡한 환경에서 API를 구축하는 데 특히 유용합니다.4
웹 서비스는 네트워크를 통한 데이터 전송을 용이하게 하는 인터넷 소프트웨어 구성 요소입니다. 웹 서비스는 애플리케이션의 데이터와 기능을 다른 애플리케이션에 노출하므로 사실상 모든 웹 서비스는 API입니다. 하지만 모든 API가 웹 서비스는 아닙니다.
API는 연결이 끊긴 두 애플리케이션 사이에서 중개자 역할을 하는 모든 소프트웨어 구성 요소입니다. 웹 서비스도 애플리케이션을 연결하지만 이를 위해서는 네트워크가 필요합니다. 웹 서비스는 일반적으로 비공개이며 승인된 사용자만 액세스할 수 있습니다.
API는 유연성을 제공하므로 기업은 새로운 비즈니스 파트너와 연결하고 기존 시장에 새로운 서비스를 제공할 수 있습니다. 이러한 유연성을 통해 기업은 수익을 높이고 디지털 혁신을 추진할 수 있는 새로운 시장에 접근할 수 있습니다.
예를 들어 Stripe라는 회사는 단 7개의 코드 라인을 가진 API로 시작했습니다. 이후 이 회사는 세계 최대의 많은 기업과 협력해 왔습니다. Stripe은 대출 및 법인 카드를 제공하기 위해 사업을 다각화했으며 최근 650억 달러의 가치 평가를 받았습니다(ibm.com 외부 링크).
개발자들을 자신의 브랜드로 끌어들이고 잠재적인 비즈니스 파트너와의 관계를 구축하기 위해 많은 기업들은 적어도 초기에는 무료로 API를 제공하는 방식을 선택합니다. API가 귀중한 디지털 자산에 대한 액세스 권한을 부여하면 기업은 액세스 권한을 판매하여 이를 수익화합니다. 이러한 관행을 API 경제라고 합니다.
AccuWeather(ibm.com 외부 링크)가 다양한 API 패키지를 판매하기 위해 셀프 서비스 개발자 포털을 시작했을 때 24,000명의 개발자를 유치하고 11,000개의 API 키를 판매하는 데 10개월밖에 걸리지 않았습니다. 이러한 움직임은 그 과정에서 번성하는 커뮤니티를 구축하는 데 도움이 되었습니다.
API는 요청하는 애플리케이션을 응답 서비스의 인프라와 분리하고 통신할 때 둘 사이에 보안 계층을 제공합니다. 예를 들어 API 호출에는 일반적으로 인증 자격 증명이 필요합니다. HTTP 헤더, 쿠키 또는 쿼리 문자열은 데이터 교환 중에 추가 보안을 제공할 수 있습니다. API 게이트웨이는 액세스를 제어하여 보안 위협을 더욱 최소화할 수 있습니다.
API는 네트워크 내에서 추가 보호 기능을 제공합니다. 또한 개인 사용자를 위한 또 다른 보호 계층을 제공할 수 있습니다. 웹사이트가 사용자의 위치를 요청하면 (위치 API가 이 정보를 제공함), 사용자는 이 요청을 허용할지 거부할지 결정할 수 있습니다.
많은 웹 브라우저와 데스크톱 및 모바일 운영 체제에는 권한 구조가 내장되어 있습니다. 앱이 API를 통해 파일에 액세스해야 하는 경우 iOS, macOS, Windows 및 Linux와 같은 운영 체제는 해당 액세스에 대한 권한을 사용합니다.
여러 클라우드에서 API 라이프사이클을 관리하고 소셜화를 촉진하며 전체 비즈니스 에코시스템에서 수익 창출 노력을 최적화하세요.
IBM 통합 솔루션을 사용하여 비즈니스 잠재력을 연결, 자동화 및 활용하세요.
온프레미스, 프라이빗 클라우드 또는 퍼블릭 클라우드 환경 내에서 호스팅되는 다양한 애플리케이션, 데이터, 비즈니스 프로세스 및 서비스를 연결하세요.
각주
1“원격 프로시저 호출”, ibm.com, 2023년 11월 3일
2“GraphQL이란 무엇인가”, Chrystal R. China, ibm.com, 2023년 12월 8일
3"REST와 SOAP 비교”, ibm.com, 2021년 3월 5일
4“GraphQL과 REST API: 차이점은 무엇인가요?,” Chrystal R. China, ibm.com, 2024년 3월 29일