API를 글로 배웠어요 (feat. REST)

API를 글로 배웠어요 (feat. REST)딥상어동의 딥한 프로그래밍/개발도구(git등)2023. 2. 9. 23:50@딥상어동의 딥한생각

Table of Contents

Interface

인터페이스란?

서로 다른 두 개의 시스템, 장치 사이에서 정보나 신호를 주고받는 경우의 접점이나 경계면. 즉 사용자가 기기를 쉽게 동작시키는데, 도움을 주는 시스템 - 위키백과

인터페이스의 정의는 "접점"/"경계면"이다. 그리고, 그 접점/경계면을 통해 정보나 신호를 주고 받는다. 대표적인 인터페이스의 예시로 컴퓨터 본체 뒷면을 들 수 있다.

https://www.samsungsvc.co.kr/solution/34210

HDMI 포트는 HDMI 케이블을 연결하여 정보를 모니터로 송출하는 인터페이스다. 모니터는 HDMI 포트라는 인터페이스를 통해 본체와 상호작용(본체의 정보를 수신하여 출력)한다.

이처럼 인터페이스는 두 가지 기능을 한다.

1. 두 대상이 만날 수 있는 접점을 제공한다.

2. 두 대상이 상호작용(=정보교환) 할 수 있도록 한다.

그런데, 한 가지 중요한 사실이 있다. 구체적으로 어떻게 작동하는지는 모른다는 것이다. 예를 들어, HDMI포트를 이용하기 위해 HDMI작동 원리를 공부할 필요는 없다. 작동 원리는 몰라도 HDMI 포트에 HDMI선을 연결해주면 모니터로 화면이 출력될 것이다 라는 것을 알고 있기 때문이다.

https://www.blackbox.co.uk/gb-gb/page/44064/Resources/Technical-Resources/Black-Box-Explains/Multimedia/What-Is-HDMI-over-Ethernet-and-How-Does-it-Work

즉, 내부적으로 어떻게 구현되어 있는지 정확히 몰라도 인터페이스만 있다면 제품을 사용할 수 있다.

다시, 요약하자면 아래와 같다.

1. 내부적으로 어떻게 구현되어 있는지는 정확이 모른다

2. 그럼에도 불구하고, 두 대상이 만날 수 있는 접점을 제공한다.

3. 그럼에도 불구하고, 두 대상이 상호작용(=정보교환) 할 수 있도록 한다.

API란?

API는 Application Proramming Interface의 약어이다. 즉, API도 Interface의 일종이다.

- 컴퓨터와 인간을 연결시키는 사용자 인터페이스와 반대로, API는 컴퓨터나 소프트웨어를 서로 연결한다. 직접 사람(최종 사용자
)에 의해 사용되도록 고안된 것이 아니며, 대신 소프트웨어에 이를 통합하고자 하는 컴퓨터 프로그래머가 사용하도록 고안되었다.

- API는 각기 다른 부분으로 구성되기도 하며 프로그래머가 사용할 수 있는 도구나 서비스의 역할을 한다. 이러한 부분들 중 하나를 사용하는 프로그램이나 프로그래머는 API의 해당 부분을 호출(call)한다고 말한다

- 위키백과 -

하드웨어에서 소프트웨어로 Interface가 연결하는 대상이 변경됐다. 앞서, HDMI예시에서의 사용자는 HDMI선을 모니터와 HDMI포트에 연결하였다. 즉, 사람과 제품 간의 명시적인 상호작용이 있었던 것이다. 하지만, API에서는 꼭 사람과 제품 간의 명시적인 상호작용이 있을 필요는 없다.

웹/앱에서 물건을 구매하면 아래와 같은 UI에서 결제 대행사를 선택할 수 있다.

결제 대행사(Application)과 온라인 쇼핑몰(Application)은 어떻게 상호작용할까?

https://www.payletter.com/ko/m/technical/index#payletter

위 이미지에서 눈에 띄는 부분은 사용자와 가맹점간의 상호작용과 가맹점과 결제시스템 간의 상호작용이 분리되어 있다는 것이다. 사용자가 온라인 쇼핑몰에서 상품을 구매하면 온라인 쇼핑몰에서 자동으로 결제시스템 API를 호출한다. 결제시스템 API 호출은 사람이 아니라 온라인 쇼핑몰이 한다.

즉, 온라인 쇼핑몰(application)과 결제시스템(application) 간의 상호작용이 발생한 것이다. 여기서 결제 요청 API는 온라인 쇼핑몰과 결제시스템이 상호작용하는 Interface가 된다. 여기까지의 설명을 읽고 나면 아래에서 API를 프로그래머가 사용한다는 것이 어떤 의미인지 어렴풋이 이해할 수 있다.

- 컴퓨터와 인간을 연결시키는 사용자 인터페이스와 반대로, API는 컴퓨터나 소프트웨어를 서로 연결한다. 직접 사람(최종 사용자)에 의해 사용되도록 고안된 것이 아니며, 대신 소프트웨어에 이를 통합하고자 하는 컴퓨터 프로그래머가 사용하도록 고안되었다.

- API는 각기 다른 부분으로 구성되기도 하며 프로그래머가 사용할 수 있는 도구나 서비스의 역할을 한다. 이러한 부분들 중 하나를 사용하는 프로그램이나 프로그래머는 API의 해당 부분을 호출(call)한다고 말한다

- 위키백과 -

마찬가지로, Interface사례에서 얘기했던 세 가지 요건을 충족한다.

1. 결제시스템이 내부적으로 어떻게 구현되어 있는지는 정확이 모른다

2. 그럼에도 불구하고, 온라인 쇼핑몰(application)과 결제시스템(application)이 만날 수 있는 접점을 제공한다.

3. 그럼에도 불구하고, 두 대상이 상호작용(=정보교환) 할 수 있도록 한다.

(온라인 쇼핑몰에서 결제 정보를 결제시스템으로 넘기고, 결제시스템은 결제 결과를 온라인 쇼핑몰로 넘긴다.)

결제 화면 안에도 네이버페이/카카오페이/토스페이/삼성페이 등 다양한 서비스들이 있다. 그리고, 그 서비스들은 api를 통해 무신사 앱과 연결된다. 이런 형태의 api를 API Gateway라고 한다.

명확히는 모르겠지만 Interface의 역할을 우리가 흔히 얘기하는 어플리케이션(지도, 메시지 등)/웹사이트 같은 소프트웨어 레벨에서 수행하면 그것을 "API"라고 부를 수 있는 것 같다.

API의 작동방식

요즘 가장 핫한 Chat-GPT를 이용해서 실제 API가 어떻게 작동하는지 알아보자.

https://chat.openai.com/chat

에 접속하여 가입후 로그인을 하면 사용자(나)는 아래의 Application(ChatGPT)를 볼 수 있다.

그리고, 제일 아래의 채팅바를 interface삼아 AI모델에 응답을 요청할 수 있다.

그러면, 사용자(나)는 AI모델로부터 아래와 같은 응답 결과를 받아볼 수 있다. (Chat GPT가 큰 충격에 빠진듯하다?)

또 다른 interface로 Regenerate response가 있다. 한번 눌러보자.

바나나를 킥하는건 불쾌한 행동이라는 답변을 받았다. 심성이 고운 친구인듯 하니 이쯤에서 그만 괴롭히자.

요약하자면, 사용자는 Application내에 있는 interface를 이용하여 AI모델에 응답을 요청한다. 그리고, AI모델은 그 요청을 바탕으로 응답을 준다.

REST API

API안에도 여러 종류가 있다. 여러 종류의 API들을 학년 내의 반에 비유해보자. 보통 반 안에는 급훈이 있다.

API안에서도 REST하다는 급훈을 따르는 반을 REST API라고 하자. REST API는 여러가지 특징을 가진다. 본 글에서 모든 특징을 설명하기는 어려워서, REST API는 stateless하다는 특징을 기준으로 설명하고자 한다. 근데, 이 stateless하다는 것 용어만 듣고는 이해하기 어렵다. stateless의 반대말은 stateful이다.

chatGPT를 이용해서 stateless의 반대말인 stateful 무엇인지 먼저 살펴보고, stateless에 대해서 알아보자. 갑자기 바나나가 먹고 싶어서 아래와 같은 질문을 했다.

그리고, 이어서 건강에 문제가 없다길래 왜 그런건지 아래의 질문을 이어서 진행했다. 그랬더니, 이자식 앞의 대화 내용을 기억하고 연관된 답변을 준다.

(Chat GPT는 먹어도 된다는데, 정작 집에 바나나가 없다 ㅜ)

여튼, ChatGPT의 답변 내용을 보았을 때 Chat GPT가 사용자의 정보(앞선 대화 내용)를 기억하고 있다는 것을 알 수 있다. 이렇게 사용자의 상태값(state)을 저장하고 있는 웹 Application을 stateful하다고 한다.

(물론, chatGPT가 서버에 응답을 요청 할 때는 REST API방식을 이용해서 응답을 요청할 것이다.)

그렇다면, 반대로 stateless하면 REST API라고 할 수 있을까? 꼭 그런건 아니다. 하지만, stateless하다는 건 REST API반의 급훈중 하나이다.

stateless하다는 것은 무엇일까? stateless에서는 현재 들어온 내용이 이전 요청 내용을 필요로 하지 않는다. 즉, 독립적이라는 의미이다. 이처럼 stateless한 서비스에서는 각각의 요청이 독립적이기 때문에 요청을 꽤나 자세히 해야 한다.

아래는 카카오톡에서 메시지를 보내는 REST API의 요청 양식이다. 자세히는 모르겠지만, 대충 봐도 받는 정보가 많다. 인증 토큰을 받기도 하고, 받는 uuid는 누구인지, 메시지 템플릿은 무엇인지, 내용은 무엇인지 등등 요청 항목이 많다.

https://developers.kakao.com/docs/latest/ko/talkcalendar/rest-api#public-event-create

이와 같은 stateless는 웹에서 사용자(클라이언트)와 서버가 상호간에 정보를 주고 받는 규칙인 HTTP의 주요 특징이다. 카카오의 경우, API가 워낙 많다보니 요청 url이 길어보이지만 REST API의 또 다른 급훈은 "단순한 요청 구조를 가져라"이다.

그리고, 그렇게 하기 위해서 API endpoint에 명사를 사용하고 행동은 HTTP Method(GET, PUT/PATCH, POST, DELETE)로 표현한다. 아래 이미지를 보면 endpoint에는 공통적으로 users라는 단순한 구조를 가지고 있고 HTTP Method로 행동이 구분되어 있다.