애플리케이션 프로그래밍 인터페이스(API)는 한 소프트웨어가 다른 소프트웨어의 기능을 사용할 수 있는 방법입니다.
이 글을 읽은 후에 다음을 할 수 있습니다:
관련 콘텐츠
인터넷에서 가장 인기 있는 인사이트를 한 달에 한 번 정리하는 Cloudflare의 월간 요약본 theNET를 구독하세요!
글 링크 복사
애플리케이션 프로그래밍 인터페이스(API)는 소프트웨어 프로그램이 다른 소프트웨어 프로그램으로 데이터를 전송할 수 있도록 하는 규칙 집합입니다.
API는 "인터페이스"로, 하나의 사물이 다른 사물과 상호 작용하는 방법을 의미합니다. 실제 예를 들어, ATM에는 화면과 여러 개의 버튼으로 구성된 인터페이스가 있어 고객이 은행과 상호 작용하고 현금 인출과 같은 서비스를 요청할 수 있습니다. 마찬가지로 API는 한 소프트웨어가 필요한 서비스를 얻기 위해 다른 프로그램과 상호 작용하는 방법입니다.
Jennifer가 출근길 통근자들이 출근 전에 고속도로 교통 상황을 확인할 수 있는 웹 사이트를 구축한다고 상상해 보세요. Jennifer는 웹 사이트 이용자에게 이 정보를 제공하기 위해 복잡한 고속도로 추적 시스템을 설정하는 데 많은 시간과 비용을 투자할 수 있습니다. 하지만 이러한 기능은 외부에서 이러한 시스템을 만들었으므로 이미 존재합니다. 이러한 방식으로 시스템을 다시 고안하는 대신 Jennifer의 웹 사이트는 외부 고속도로 추적 서비스에서 제공하는 API를 사용합니다. 이제 Jennifer는 웹 사이트의 다른 측면을 구축하는 데 집중할 수 있습니다.
API 호출은 API 요청이라고도 하며, API 사용을 트리거하는 API에 보내는 메시지입니다.
API 호출이 작동하려면 API의 요구 사항에 따라 형식을 지정해야 합니다. API의 요구 사항을 "스키마"라고 합니다. 스키마에서는 각 요청에 제공되는 응답 유형도 설명됩니다.
통근자가 Jennifer의 웹 사이트를 이용하여 192번 고속도로의 교통 상황을 확인한다고 가정해 보겠습니다. 웹 사이트에서는 이 정보를 제공하기 위해 API 호출을 전송합니다("고속도로 192"라는 메시지). 고속도로 추적 서비스의 API 서버에서는 이 메시지를 수신하고 192번 고속도로의 이동 시간을 회신합니다. API의 스키마를 다음과 같은 방식이라고 상상해 보세요.
| API 요청 | API 응답 |
|---|---|
| "192번 고속도로" | 192번 고속도로의 이동 시간 |
| "217번 고속도로" | 217번 고속도로의 이동 시간 |
| "225번 고속도로" | 225번 고속도로의 이동 시간 |
(이는 매우 단순화된 예시이며 실제 API 요청, 응답, 스키마는 더 복잡합니다.)
이제 Jennifer의 웹 사이트에서 "ASDFGHJ 고속도로"에 대한 API 요청을 보낸다고 가정해 보겠습니다. 이는 실제 고속도로 이름만 허용하는 API의 스키마를 따르지 않으므로 유효한 요청이 아닙니다. 서버는 이러한 요청에 대해 사용 가능한 응답을 제공할 수 없습니다.
엔드포인트는 커뮤니케이션 채널의 끝을 의미합니다. API 엔드포인트는 API 응답이 시작되는 곳입니다.
이 예에서 API 연결의 클라이언트는 Jennifer의 웹 사이트이고 엔드포인트는 API를 호스팅하는 서버입니다.Jennifer의 API 호출은 API 서버가 담당하는 특정 URL로 이동해야만(URL은 www.cloudflare.com/learning과 같은 웹 주소입니다)응답을 받을 수 있습니다.
API 통합은 API를 사용하여 두 개 이상의 애플리케이션을 결합하는 것입니다. 영업팀과 마케팅팀을 한 사무실에 통합하면 두 팀이 함께 일하고 서로의 노력을 통해 이점을 누릴 수 있는 것처럼, API 통합도 한 애플리케이션이 다른 애플리케이션의 기능을 활용할 수 있게 해줍니다. API 통합은 일반적으로 두 애플리케이션 또는 데이터베이스 간에 데이터를 동기화하는 데에도 사용됩니다.
운영 체제부터 소프트웨어 라이브러리까지 컴퓨터 코드와 관련된 모든 것에는 API가 있을 수 있습니다. 웹 API는 특히 인터넷을 통해 액세스하는 웹 애플리케이션에서 사용하기 위한 것입니다.
웹 API는 요즘 인터넷에서 매우 중요한 역할을 합니다. 거의 모든 사용자 대면 애플리케이션은 API에 의존하여 작동합니다(Jennifer의 웹 사이트뿐만 아니라!). 소프트웨어 개발 철학은 모두 API 사용에 의존합니다. 이러한 철학 중 하나가 JAMstack이며, 여기서 JAM은 JavaScript, API, markup의 약자입니다. 또 다른 예는 마이크로서비스 아키텍처로, 애플리케이션을 구성하는 다양한 기능을 호출하기 위해 API를 사용합니다. 이러한 접근 방식 없이 구축된 애플리케이션도 일반적으로 API에 의존합니다.
SOAP API와 REST API는 서로 다른 범주의 API를 설명합니다.
단순 객체 접근 프로토콜(SOAP)은 프로토콜의 한 유형입니다.SOAP API는 SOAP 프로토콜만 사용하는 API입니다.
웹 표현 상태 변경(REST)은 웹 서비스를 위한 아키텍처 스타일입니다. REST API는 REST 아키텍처를 사용하여 구축된 모든 API입니다. SOAP API와 달리 REST API는 모든 프로토콜에서 작동합니다. 오늘날 대부분의 API는 REST API입니다.
애플리케이션을 사용하도록 허용하면 해당 사용자가 애플리케이션을 남용할 위험이 있는 것처럼, API를 사용하면 API 클라이언트가 서비스를 남용할 위험이 있습니다. 또한 웹 API 호출은 인터넷을 통해 이동하므로 네트워크를 통한 다른 데이터 전송과 마찬가지로 가로채거나 스푸핑하거나 수정할 수 있습니다.
API 보안은 공격과 남용으로부터 API를 보호하는 관행입니다. 최근 인터넷에서 API의 중요성을 고려할 때 API 보안은 웹 앱 보안의 핵심 구성 요소입니다. 중요한 API 보안 조치에는 다음이 포함됩니다.
Cloudflare API Gateway에는 API 위협으로부터 보호하기 위한 이러한 보안 기능과 기타 보안 기능이 포함되어 있습니다. API 보안에 대해 자세히 알아보려면 API 보안이란?을 참조하세요.