앱끼리 대화하는 창구, API

사람용 화면과 앱용 창구

앞에서 우리는 요청을 보내면
응답이 돌아온다고 배웠어요.
사람이 받는 응답은 보통 웹페이지예요.
글자도 있고 그림도 있고 버튼도 있죠.
사람 눈에는 보기 좋지만
앱이 쓰기엔 너무 복잡해요.
그래서 앱끼리는 화면 말고
곧장 쓸 수 있는 데이터를 주고받아요.
그 약속된 창구를 API라고 불러요.

사람용 화면과 앱용 창구를 눌러 비교해봐요. 어느 쪽이 앱이 쓰기 좋은가요?

같은 정보라도 모습이 달라요.
사람에겐 보기 좋게 꾸민 화면을,
앱에겐 군더더기 없는 데이터를 줘요.
화면은 사람이 읽으라고 만든 거고,
창구는 앱이 읽으라고 만든 거죠.
그렇다면 앱은 그 창구에
어떻게 말을 거는 걸까요?
다음 단계에서 요청하는 법을 봐요.

정해진 형식으로 요청해요

창구에 아무렇게나 말하면 안 돼요.
미리 정해 둔 형식대로 물어봐야 해요.
예를 들면 '서울의 날씨를 알려 줘' 같은
약속된 요청이에요.
식당에서 메뉴판을 보고
정해진 이름으로 주문하는 것과 비슷해요.
주문이 약속된 말이면
주방은 헷갈리지 않고 바로 만들죠.
API도 약속된 요청만 알아들어요.

약속된 요청을 눌러 API에 보내봐요. 정해진 형식이라 창구가 바로 알아들어요.

요청을 보냈으니
이제 답이 올 차례예요.
사람에게 보내는 화면 대신
API는 무엇으로 답할까요?
앱이 곧장 쓸 수 있게
깔끔하게 정리된 데이터로 답해요.
그 데이터가 어떻게 생겼는지
다음 단계에서 펼쳐 봐요.

그림이 아니라 데이터로 답해요

API의 답은 그림이 아니에요.
이름과 값이 짝지어진 데이터예요.
예를 들면 온도는 23,
하늘은 맑음, 이런 식이죠.
이름이 있어서 무슨 값인지 분명해요.
이렇게 이름과 값으로 적는 방식을
흔히 JSON이라고 불러요.
앱은 이 데이터에서 필요한 값만
쏙 골라 자기 화면에 써요.

데이터를 눌러 펼쳐봐요. 그림이 아니라 이름과 값(온도 23, 맑음)으로 깔끔하게 답해요.

값마다 이름이 붙어 있으니
앱은 헷갈리지 않아요.
온도가 필요하면 온도를,
날씨가 필요하면 날씨를 꺼내 쓰죠.
그림이라면 일일이 알아봐야 하지만
데이터는 곧장 쓸 수 있어요.
그런데 이런 창구가 하나만 있는 건 아니에요.
날씨 창구, 지도 창구, 여러 창구가 있죠.
그럼 둘 이상을 합치면 어떨까요?

창구를 조합해 새 서비스를 만들어요

창구 하나하나는 한 가지 일만 해요.
지도 창구는 위치를 알려 주고,
날씨 창구는 날씨를 알려 주죠.
그런데 둘을 합치면 어떨까요?
지도 위에 그 자리의 날씨를 띄우는
새로운 서비스가 생겨요.
블록을 끼워 맞추듯
여러 창구를 모아 더 큰 걸 만드는 거예요.
우리가 쓰는 앱들이 이렇게 만들어져요.

지도 API와 날씨 API를 차례로 눌러 합쳐봐요. 둘을 합치면 지도 위에 날씨가 뜨는 새 서비스가 돼요.

두 창구의 데이터가 만나니
혼자선 못 하던 일이 생겼죠.
지도도 날씨도 처음부터 만들 필요 없이,
이미 있는 창구를 빌려 합쳤을 뿐이에요.
그래서 새 서비스를 빠르게 만들 수 있어요.
바퀴를 다시 깎지 않고
잘 만든 부품을 가져다 쓰는 거죠.
이게 API가 세상을 바꾼 방식이에요.

정리해볼까요

한 줄로 모으면 이래요.
사람은 화면을 보지만 앱끼리는 데이터를 주고받아요.
그 약속된 창구가 API예요.
정해진 형식으로 요청하면
그림이 아니라 이름과 값의 데이터로 답해요.
여러 창구를 조합하면 새 서비스가 되죠.
그래서 우리는 모든 걸 처음부터 만들지 않고
이미 있는 창구를 빌려 새것을 만들 수 있어요.

핵심을 차례로 눌러 되짚어봐요. (앱용 창구 → 정해진 형식으로 요청 → 데이터로 답 → 조합해 새 서비스)

이제 앱들이 어떻게
서로 데이터를 주고받는지 알게 됐어요.
눈에 보이는 앱 하나 뒤에는
수많은 창구가 조용히 일하고 있죠.
다음에 날씨 앱을 열 때
떠올려 봐요.
저 화면은 어느 창구에서
어떤 데이터를 받아 온 걸까,
하고요.