API(Application Programming Interface)란?

애플리케이션 소프트웨어를 빌드하고 통합하기 위한 정의 및 프로토콜 세트인 애플리케이션 프로그래밍 인터페이스

API는 당사자들 간 계약을 나타내는 Documentation을 갖춘 계약으로 비유되기도 한다. 한쪽 당사자가 특정한 방식으로 구성된 원격요청을 보내면 다른 쪽 당사자의 소프트웨어가 이에 응답하는 방식이다.

• 빠르고 신속한 변화에 맞춰 개발/배포할 수 있도록 지원한다.

• 클라우드 네이티브 애플리케이션 개발: 개발 속도를 높이기 위한 식별 가능한 방식이며, API를 통한 마이크로 서비스 애플리케이션 아키텍쳐 연결에 기반한다.

• API는 클라우드 네이티브 애플리케이션 개발을 통해 자체 인프라를 연결하는 간소화된 방식이지만, 고객 및 다른 외부 사용자와의 데이터 공유를 허용하기도 합니다. 퍼블릭 API는 파트너와의 연결 방식을 간소화하고 확대할 수 있을 뿐만 아니라 보유한 데이터를 활용해 수익을 창출할 수 있다(예: Google Maps API).

• API는 리소스에 대한 액세스 권한을 제공하고 보안과 제어를 유지할 수 있게 해주며 액세스 권한을 어떻게, 누구에게 제공할지 여부만 결정하면 된다.

  API 보안이란 결국 효과적인 API 관리를 의미하며, 여기에는 API 게이트웨이 사용이 포함된다. 레거시 시스템과 사물 인터넷(IoT)을 비롯해 어떤 환경이든 연결하는 분산형 통합 플랫폼을 통해 API에 연결하고 API에 의해 노출된 데이터 또는 기능을 사용하는 애플리케이션을 만들 수 있다.

API의 기능

• 구현 방식을 알지 못하는 제품/서비스와 통신 가능
• 애플리케이션 개발을 간소화해 시간과 비용을 절약할 수 있다.
• 새로운 툴과 제품을 설계하거나 기존 툴과 제품을 관리할 때 API를 사용하면 유연성을 높이고 설계, 관리, 사용 방법을 간소화해, 혁신을 일으킬 수 있다.

API 의 종류

• 프라이빗
  API를 내부에서만 사용할 수 있도록 하며, 기업이 API를 최대한으로 제어할 수 있습니다.

• 파트너
  API를 특정 비즈니스 파트너와 공유하며, 품질 저하 없이 추가 수익원을 창출할 수 있습니다.

• 퍼블릭
  API가 모두에게 제공되며, 제 3자가 API와 상호 작용하는 애플리케이션을 개발하여 혁신을 끌어낼 수 있습니다.

원격/웹 API와 REST

PI에 의해 조작되는 리소스가 요청을 보내는 컴퓨터의 외부에 있는, '원격' API는 커뮤니케이션 네트워크를 통해 상호 작용하도록 설계되었다. 가장 광범위하게 사용되는 커뮤니케이션 네트워크가 인터넷이기에 대부분의 API는 웹 표준을 기반으로 설계되며, 모든 원격 API가 웹 API인 것은 아니지만 웹 API가 원격이라고 가정할 수는 있다.

웹 API는 일반적으로 요청 메시지에 HTTP를 사용하여 응답 메시지 구조의 정의를 제공한다. 이러한 응답 메시지는 일반적으로 다른 애플리케이션이 쉽게 조작할 수 있는 방식으로 데이터를 표시하므로 XML 또는 JSON 파일의 형태가 자주 사용된다.

정보교환 표준화를 위한 SOAP 프로토콜 사양

웹 API가 확산됨에 따라, 정보 교환을 표준화하기 위해 SOAP(Simple Object Access Protocol)라는 프로토콜 사양이 개발되었다. SOAP로 설계된 API는 XML 메시지 형식을 사용하며 HTTP 또는 SMTP를 통해 요청을 수신합니다. SOAP를 사용하면 더 간편한 방법으로 애플리케이션을 다양한 환경에서 실행하거나 다양한 언어로 작성하여 정보를 공유할 수 있습니다.

정보교환 표준화를 위한 REST 사양

또 다른 사양은 REST(Representational State Transfer)로, REST 아키텍처의 제약 조건을 준수하는 웹 API를 RESTful API라 한다.

SOAP는 프로토콜이지만 REST는 아키텍처 스타일이라는 근본적인 차이가 있으며 따라서 RESTful 웹 API에는 공식적인 표준이 없다. 규정된 프로토콜보다는 훨씬 간단해, RESTful API가 SOAP보다 더 많이 사용되고 있다. Roy Fielding의 논문인 '네트워크 기반 소프트웨어 아키텍처의 구조적 스타일과 설계(Architectural Styles and the Design of Network-based Software Architectures)'에 정의된 것처럼 6가지 주요 제약조건을 준수했을 때 RESTful API라고 간주할 수 있다.

RESTful 시스템의 다음 6가지 주요 제약 조건

• 클라이언트 서버 아키텍처: REST 아키텍처가 클라이언트, 서버, 리소스로 구성되며 HTTP를 통해 요청을 처리한다.
• 스테이트리스: 요청이 통과하는 서버에는 클라이언트 콘텐츠가 저장되지 않으며 그 대신 세션 상태에 대한 정보가 클라이언트에 저장된다.
• 캐시 가능성: 캐싱으로 일부 클라이언트-서버 간의 상호 작용이 제거된다.
• 계층화된 시스템: 추가 계층으로 클라이언트-서버 간의 상호 작용을 조정할 수 있으며 이러한 계층은 로드 밸런싱, 공유 캐시 또는 보안과 같은 추가 기능을 제공할 수 있다.
• 코드 온디맨드(옵션): 서버가 실행 가능한 코드를 전송하여 클라이언트의 기능을 확대할 수 있다.
• 통합된 인터페이스: RESTful API 설계의 핵심. 다음의 4가지 측면을 포함
  • 요청에서 리소스 식별: 리소스가 요청에서 식별되며 클라이언트로 반환된 표현으로부터 분리된다.
  • 표현을 통한 리소스 조작: 클라이언트가 리소스를 나타내는 파일을 수신한다. 이 표현에는 조작 또는 삭제를 허용할 수 있도록 충분한 양의 정보가 포함되어야 한다.
  • 자기 기술적(Self-descriptive) 메시지: 클라이언트에 반환되는 각 메시지에 클라이언트가 정보를 어떻게 처리해야 할지 설명하는 정보가 충분히 포함되어야 한다.
  • 애플리케이션 상태 엔진으로서의 하이퍼미디어: 리소스를 할당한 후 REST 클라이언트가 하이퍼링크를 통해 현재 사용 가능한 기타 모든 작업을 찾을 수 있어야 한다.

SOAP, REST 사양 그외의 표준 사양

OpenAPI 사양은 REST API를 정의하는 공통 표준으로 부상했다. OpenAPI를 통해 개발자들은 언어 독립적인 방식으로 REST API 인터페이스를 구축할 수 있으므로 사용자는 별다른 추측 없이도 이를 이해할 수 있다.

부상하는 또 다른 API 표준은 쿼리 언어이자 서버측 런타임으로 REST의 대안인 GraphQL이다. GraphQL은 클라이언트에게 요청한 만큼의 데이터를 제공하는 데 우선순위를 둔다. REST를 대체할 수 있는 GraphQL은 개발자가 단일 API 호출로 다양한 데이터 소스에서 데이터를 끌어오는 요청을 구성할 수 있도록 지원한다.

참고 자료: https://www.redhat.com/ko/topics/api/what-are-application-programming-interfaces