API 개념 이해하기

오늘은 API에 대해 정리를 해보려고 한다.

 

API란? 

application programming interface의 약자로, 굳이 풀이한다면 애플리케이션 프로그래밍 인터페이스, 응용 프로그램 프로그래밍 인터페이스라고 풀면 되겠다.

 

다른 블로그를 찾아보니 자판기에 비유해서 표현하니 이해가 쉬웠다.

우리가 자판기를 사용할때 어떤 원리로 작동하는지는 모르지만 사용하기 편하게 직관적일수록 사용하기 더 좋은 기계라고 볼 수 있는것처럼 인터페이스를 통해 쉽고 편하게 만들어진 규격이라고 생각하면 된다.

 

API의 종류?

지금 내가 사용하는 API는 가장 대표적인 두가지 방식인 SOAP와 REST인데, 찾아보니 두 방식은 비슷하지만 본질적으로 다른 기술이라고 한다. 그래서 비교를 해보려고 한다.

 

차이	SOAP	REST
유형	Protocol	Architecture
기능	구조화된 정보 전송 ACID(원자성, 일관성, 고립성, 지속성)	데이터를 위해서 리소스에 접근(URL)
데이터 포워딩	xml	plain/text, HTML, XML,JSON 등등
보안	ws-security,ssl지원	ssl과 HTTPS지원
대역폭	많은 리소스와 대역폭 요구	적은 리소스와 가벼운 무게
데이터 캐시	캐시x	캐시o
페이로드 처리	엄격한 통신규약을 가지고있어 모든 메세지를 보내기 전 알려야함	알려줄 필요없다
ACID준수	자체적인 ACID기준이 있어 데이터 손상을 줄여줌	X

 

- SOAP

SOAP 방식은 Simple Object Access Protocol 의 약자이며, 다른 언어로 다른 플랫폼에서 빌드된 애플리케이션이 통신할 수 있도록 설계된 최초의 표준 프로토콜이다.

 

프로토콜이기 때문에 복잡성과 오버페드를 증가시키는 빌트인 룰을 적용하므로 페이지 로드 시간이 길 수 있다.

그래서 기업에서 선호하는 방식이기도 하다. 이러한 표준은 빌트인 컴플라이언스를 제공한다는 의미이기 때문이다.

 

빌트인 컴플라이언스 표준에는 보안과 안정적인 데이터베이스 트랜잭션의 기본 속성인 원자력, 일관성, 격리성, 내구성(ACID)가 포함된다.

 

일반적인 웹 서비스 사양에는 다음이 포함된다.

• 웹 서비스 보안(WS-security): 토큰이라고 불리는 고유 식별자를 통해 메시지를 보호하고 전송하는 방식을 표준화한다.
• WS-ReliableMessaging: 불안정한 IT 인프라로 전송되는 메시지 간 오류 처리를 표준화한다.
• 웹 서비스 주소지정(WS-addressing): 심층 네트워크에 라우팅 정보를 유지관리하는 대신, SOAP 헤더 내에 메타데이터로 해당 정보를 패키징한다.
• 웹 서비스 기술 언어(WSDL): 웹 서비스가 무엇을 하는지, 해당 서비스의 시작과 종료 위치를 기술한다.

데이터에 대한 요청이 SOAP API로 전송되는 경우 HTTP(웹 브라우저), SMTP(이메일), TCP 등의 다양한 애플리케이션 레이어 프로토콜을 통해 처리될 수 있다.

 

요청이 수신되면, 인간과 기계가 모두 읽을 수 있는 마크업 언어인 XML 문서 형식으로 반환된다.

SOAP API에 대한 완료된 요청은 브라우저에서 캐시할 수 없으므로, API로 재전송하지 않는 한 이후에 액세스할 수 없다.

 

- REST

REST 방식은 Representational State Transfer 의 약자이며 웹 서비스와 모바일 애플리케이션 경량화의 필요에 맞춘 아키텍처 스타일이다. 

 

가이드라인이기 때문에 권장 사항의 구현 여부는 개발자에 따라 달라진다.

데이터 요청은 일반적으로 하이퍼텍스트 전송 프로토콜(HTTP)을 통해 이루어진다. 이러한 요청을 수신하면 REST용으로 설계된 API(RESTful API 또는 RESTful 웹 서비스)가 HTML, XML, 일반 텍스트, JSON과 같은 다양한 형식으로 메시지를 반환할 수 있다. 

 

RESTful API의 장단점

장점

• 표준 기반 : HTTP 표준을 활용해 배우기 쉽고, 다양한 클라이언트와 호환 가능.
• 확장성 : 무상태성 덕분에 서버 확장이 용이.
• 가독성/일관성 : URI 구조와 메서드만 보고도 API의 역할을 직관적으로 이해 가능.

단점

• 엄격하지 않은 정의 : “RESTful” 여부는 정도 차이가 있음. (REST 원칙을 모두 지키는 경우는 드묾)
• Over-fetching/Under-fetching 문제 : 필요한 데이터만 주고받기 어렵다. → GraphQL 등장 배경.
• 복잡한 트랜잭션 처리 : 여러 리소스를 동시에 갱신해야 하는 경우 제약이 있다.

좋은 글 추천 : https://lob-dev.tistory.com/90