API Application Programming Interface
정의
API는 정의 및 프로토콜 집합을 사용하여 두 소프트웨어 구성 요소가 서로 통신할 수 있게 하는 메커니즘이다.
- 서로 다른 애플리케이션이 통신할 수 있도록 하는 정의된 규칙의 집합
- API의 맥락에서 Application이라는 단어는 고유한 기능을 가진 모든 소프트웨어를 의미
- Interface는 두 애플리케이션 간의 서비스 계약이며, 이 계약은 요청과 응답을 사용하여 두 애플리케이션이 서로 통신하는 방법을 정의함.
- API 문서에는 개발자가 이런 요청과 응답을 구성하는 방법에 대한 정보가 들어있음.
- 시스템 간 데이터 전송을 처리하는 중간 계층으로 작용하여 회사가 응용프로그램 데이터와 기능을 외부 제 3자 개발자, 파트너 및 내부 부서에 개방할 수 있게 함.
- 다른 시스템과 애플리케이션이 데이터와 서비스와 상호 작용할 수 있는 표준화된 방법을 생성
- 외부와의 연동, 데이터 공유, 서비스 제공 등을 효과적으로 구현
작동방식
API 아키텍처는 일반적으로 클라이언트와 서버 측면에서 설명된다. 요청을 보내는 애플리케이션을 클라이언트라고 하고 응답을 보내는 애플리케이션을 서버라고 한다.
보통 HTTP 프로토콜을 기반으로 클라이언트는 HTTP 메서드(GET, POST, PUT, DELETE 등)를 사용하여 요청을 보내고, API 서버는 이를 처리하고 적절한 응답을 반환한다.
분류
분류는 어떤 것을 기준으로 하냐에 따라 너무 다양해져서 amazon에서 분류한 API의 통신 방식, 사용 목적, 아키텍처 스타일 등을 고려한 방법으로만 기술함.
- SOAP API
- 단순 객체 접근 프로토콜 사용
- XML 기반 통신 프로토콜
- 복잡한 기업간 통신이나 시스템 간 통합에 주로 사용
- 보안, 트랜잭션 관리 등 다양한 기능 제공
- WSDL(Web Services Description Language)같은 명시적 인터페이스 정의를 통해 서비스 구조를 미리 정의
- 과거에 더 많이 사용, 유연성이 떨어지는 API
- RPC API
- 원격 프로시저 호출방식
- 클라이언트가 서버에 요청을 보내면 서버는 해당 요청을 처리하고 결과를 반환
- 분산 시스템이나 클라이언트-서버 환경에서 사용
- 서버의 메서드를 클라이언트가 직접 호출하는 방식으로 동작
- WebSocket API
- 양방향 실시간 통신을 위한 API
- 클라이언트와 서버간 지속적인 연결 유지
- 양쪽 언제든 데이터 보내기 가능
- 실시간 채팅, 주식 시세 업데이트, 멀티플레이어 게임 등 실식간 데이터 전송이 필요할 때 사용
- REST API
- Representational State Transfer의 웹 기반 아키텍처 스타일을 따르는 API
- 클라이언트와 서버 간의 통신을 위한 표준적인 방식
- HTTP 프로토콜 기반
- 자원을 URL로 표현
- HTTP 메서드 사용, 자원에 대한 CRUD 작업 수행
- 단순, 가볍, 확장 가능한 API 설계 지향
- 대부분의 웹 API는 RESTful한 아키텍처를 따름
Web API
Web API 또는 웹 서비스 API는 웹 서버와 웹 브라우저 간의 애플리케이션 처리 인터페이스이다. 모든 웹 서비스는 API이지만 모든 API가 웹 서비스는 아님.
정말 여러 Web API가 있지만, 대표적으로 REST API, GraphQL API, WebSocket API 등이 있다.
Google, Twitter, Facebook, Github 등 기업이 제공하는 고유한 API도 많고 해당 기업의 서비스와 기능을 활용할 수 있음.
API를 둘러볼 수 있는 사이트
- Public APIs: Public APIs는 다양한 카테고리와 수많은 API를 제공하는 오픈 API 디렉토리입니다. 해당 사이트에서 카테고리별로 API를 검색하고 문서를 확인할 수 있다.
- RapidAPI: RapidAPI는 다양한 API를 검색하고 사용할 수 있는 플랫폼으로, 다양한 카테고리와 API를 제공한다. 해당 사이트에서 API를 검색하고 관련 문서와 예제 코드를 확인할 수 있습니다.
- AnyAPI: AnyAPI는 다양한 카테고리와 수백 개의 API를 포함하는 API 디렉토리. 해당 사이트에서 원하는 카테고리를 선택하고 API를 검색할 수 있다.
- Google Developers: Google Developers는 Google이 제공하는 다양한 API와 관련된 문서 및 자료를 제공하는 플랫폼. 해당 사이트에서 Google API 및 다른 관련 API에 대한 정보를 확인할 수 있다.
추가 궁금증
위에 설명된 API들은 전부 TCP 프로토콜 기반 API라 UDP 기반으로 동작하는 API도 궁금해짐.
UDP 기반으로 동작하는 API
-
DNS API (Domain Name System): DNS는 도메인 이름을 IP 주소로 해석하는 역할을 함. DNS API는 UDP를 통해 DNS 서버와 통신하여 도메인 이름 해결을 요청하고 응답을 받을 수 있다.
-
TFTP API (Trivial File Transfer Protocol): TFTP는 간단한 파일 전송을 위한 프로토콜. 파일 전송 및 다운로드를 UDP를 통해 수행. TFTP API를 사용하여 파일 전송 기능을 구현.
-
RTP (Real-time Transport Protocol): RTP는 실시간 멀티미디어 데이터를 전송하기 위한 프로토콜. 오디오나 비디오 스트리밍에 주로 사용. RTP는 UDP를 기반으로 하며, RTP API를 사용하여 실시간 멀티미디어 데이터의 전송과 관련된 기능을 구현할 수 있다.
GraphQL과 REST, 병행할 수 있을까?
결론부터 말하면 하나의 목표(리소스)를 위해 두 API Structure를 섞는 건 품질을 떨어뜨릴 수 있다.
(ex: 사용자 정보를 등록하는 것은 RESTful API 로, 사용자 정보를 수정하는 것은 GraphQL API 로 한다면 끔찍할 것이다.)
꼭 하나만 선택하라는 법은 없다. 우선 각 API의 장단점은 이전 포스팅에서 정리했고, 두 개를 병행하는 경우의 수는 생각해보지 못해서 찾아보았다.
우선 간단히 이런 기준으로 보통 둘 중 하나를 선택하여 사용한다.
GraphQL
- 서로 다른 모양의 다양한 요청들에 대해 응답할 수 있어야 할 때
- 대부분의 요청이 CRUD(Create-Read-Update-Delete) 에 해당할 때
RESTful
- HTTP 와 HTTPs 에 의한 Caching 을 잘 사용하고 싶을 때
- File 전송 등 단순한 Text 로 처리되지 않는 요청들이 있을 때
- 요청의 구조가 정해져 있을 때
File 전송 같이 RESTful이 더 유리한 API가 있을 수 있고 다양한 정보를 주고 받는 것 같이 GraphQL이 더 유리한 API가 있을 수 있다.
하나의 Endpoint를 GraphQL로 만들고, 다른 RESTful Endpoint들을 만들어 놓는 건 개발자의 자유.
장단점을 잘 파악하여 결정하는 것이 좋다.
참조 ✅
