API가 도대체 뭐야? 이걸로 끝내자

 

백엔드 개발을 시작하고 나서 정말 자주 API라는 단어를 사용하고, 프로젝트를 하며 여러 API를 만들긴 만들었다. 하지만! API가 뭐야?라는 질문에 “어 그거 그 서버랑 연결해서.. 그 응답해주고.. 그 인터페이스…”라며 쉽사리 대답하지 못하는 나를 보고 다시 한번 API에 대해 천천히 살펴보게 되었다.

분명 나와 같은 고민을 하는 사람들이 아주 많을 것이라고 생각하고 조금이라도 이 글이 도움이 되었으면 한다 🙇

 

 

---

 

Application Programming Interface(API)

1️⃣  An application programming interface(API) is a way for two or more computer programs to communicate with each other.
2️⃣ API는 응용 프로그램에서 사용할 수 있도록, 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻한다.

→ Inter(상호간의) + face(마주하는) = Interface(서로 다른 두개의 물체가 상호간에 정보나 신호를 주고받기 위해 필요한 접점이나 경계면)

 

즉, 두개 이상의 프로그램들이 서로 소통하기 위한 방법, 접점이라고 생각하면 접근하기 쉬울 것이다.

 

기본적으로 API는 요청과 응답을 통해 프로그램/애플리케이션 사이를 중재 or 소통한다. 소통의 방법, 표현의 방법을 통일하여 개발자들의 의사소통을 돕기 위해 API는 사용된다.

( 생성된 시기와 이유에 따라 SOAP API, RPC API, Websocket API, REST API가 있고 자세한 내용들은 다른 곳에서 이미 충분히 잘 설명되어지고있으니 이번에는 간단히 언급하고 넘어가도록 하겠습니다.)

 

그 중 REST는 가장 널리 사용되고 있는 API 설계 규칙이고 REST API는 REST 아키텍처의 제약 조건을 준수하는 애플리케이션 프로그래밍 인터페이스이다.

 

📌 REST API(Representational State Transfer API)

REST API는 HTTP의 개발자가 기존의 HTTP 프로토콜을 제대로 사용해보자는 입장에서 개발을 하게 되었다고 한다. 그렇기에 HTTP를 베이스로 한 통신이 분명할테고 그 통신의 방법을 어떻게？ 가져갈지 알아야할 것이다.

 

👉  HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다.

 

쉽게 말하면, 자원을 이름으로 구분하여 해당 자원의 정보(상태)를 HTTP URI와 HTTP method를 사용해 주고 받는 것을 의미한다.

이런 REST API는 위에서 잠깐 언급한 “REST 아키텍처의 6가지 제약조건”을 준수해야하는데 그 사항들이 REST API의 큰 특징이 된다.

 

<REST 아키텍쳐의 6가지 제약조건>

• Server-Client 구조
  • 데이터를 저장하는 데이터 스토리지 부분과, 이를 활용하고 서비스를 구동하는 유저 인터페이스를 분리하 는 것 → 독립적 개발 가능 → 확장성과 활용성 증가
  • (일반적으로 API는 앱 대 앱 형식을 따르지만 REST는 클라이언트-서버를 따른다)
• self-descriptiveness
  • 직관적으로 개발자 사이의 의사소통을 수월하게 구성된 API는 통신 이해도를 높이며, 제공하는 자원에 대한 정보를 명확히 기술할 수 있다.
  • REST API를 사용한다고 하지만 대부분이 잘 지키지 못하는 제약조건이라고 한다
• Stateless(무상태)
  • 상태에 대한 정보를 따로 저장하거나 관리 하지 않는 것(HTTP의 특성이다)
• Cacheable(캐시 처리 기능)
  • 요청에 대한 응답 내의 데이터에 해당 요청은 캐시가 가능한지 불가능 한지 명시해야 한다.
  •  응답을 캐시 할 수 있다면 클라이언트에서 동일한 요청이 왔을 때 응답 데이터를 재사용할 수 있어야 하고 cache-control 헤더를 통하여 캐시 여부를 명시한다.
• Layered System(계층화)
  • 서버는 클라이언트가 모르게 API 서버에 여러 계층을 추가하여 유연한 구조로 개발될 수 있다 → Layered Architecture가 Rest의 특징인지는 몰랐다..
• Code-On-Demand(Optional)
  • 클라이언트는 리소스에 대한 표현을 응답으로 받고 처리해야 하는데, 어떻게 처리해야 하는지에 대한 Code를 서버가 제공하는 것을 의미한다*( 이 부분이 이해가 가지 않습니다..혹시 아시는 분은 댓글로 설명해주시면 감사하겠습니다)*

👉 아직 특징들에 대해 정확하게 이해하기가 조금 어려운 것 같다. 나중에 다시 한번 정리하는 시간을 가져야겠다.

📌 SOAP

SOAP(Simple Object Access Protocol)란 컴퓨터 네트워크에서 웹 서비스를 구현할 때 구조화된 정보를 교환하기 위한 간단한 개체 액세스 프로토콜입니다. 보안수준이 엄격하여 높은 보안 수준을 요구하는 은행 앱이나 신뢰할 수 있는 메세징 앱에서 선호됩니다

REST API vs SOAP

REST와 SOAP은 전세계에서 가장 보편화되어 사용되고 있는 웹 API 패러다임이다. 두 개념을 비교하여 많이 설명해서 동일한 계층에 있는 개념 같지만 본질적으로 다른 기술이라 직접적으로 비교하는 것은 적당하지 않은 것 같다

1. SOAP은 프로토콜이고, REST는 api 설계 스타일(아키텍처)이다.
2. REST는 앞서 언급한대로 리소스(데이터) 중심으로 묘사되지만, SOAP은 행위, 기능 중심으로 서술된다.
3. REST는 여러가지 형태의 데이터 (html, json, text)를 전송할 수 있지만, SOAP은 XML 데이터만을 고정적으로 전송하도록 만들어졌다.(웹상에서 REST가 보편적인 이유)

 

📌 Websocket API

주식거래 사이트를 생각해보면 가격이라던지 숫자들이 실시간으로 변하는 것을 확인할 수 있다. 만일 rest api로 구성했다면 새로고침을 쉴새없이 누르며 서버에 데이터를 요청해야할 것이고 변동이 없는 데이터들까지도 반복적으로 요청이 되어 엄청난 자원이 낭비될 것이다. 그렇기에 Websocket API를 사용하면 클라이언트는 필요한 데이터에 대해 한번 요청을 하면 서버와 채널이 열리게 되고 그 채널을 통해 계속해서 데이터들이 서버에서 클라이언트로 흘러가게 되는 것이다. 

많이들 REST API는 요청할 때 마다 방문을 열어서 응답을 하고, 다시 방문을 닫는 방식이라고 말을하고 Websocket API는 수도꼭지를 열어 물이 흘러 하수도로 끊임없이 흘러나가는 방식이라곡 비유를 하기도 하는데 이해하기에 큰 도움이 되었던 것 같다.

✨ 채팅,주식거래,위치 기반 서비스, 스포츠경기 데이터, 온라인 게임 ✨등에 사용된다고 한다.

Websocket API는 클라이언트 앱과 서버 간의 양방향 통신을 지원한다. 서버가 연결된 클라이언트에 콜백메시지를 전송할 수 있다.

 

 

 

참고

---

• http://www.incodom.kr/RestFul_API
• https://restfulapi.net/
• https://www.youtube.com/watch?v=LddPLO4bXmQ&t=181s
• https://hwasurr.io/api/rest-graphql-differences/