작성자 : 기획마케팅부 박수빈 사원
✔ 프롤로그
◼ 1. API가 뭔데?
예시의 과정을 API에 빗대어 이야기하자면, 주문을 했던 손님은 요청하는 클라이언트 즉, 사용자가 되고 메뉴판은 API 목록들이 적혀 있는 목록이 되고 주방장은 요청을 처리하는 서버의 역할을 맡게 됩니다.
◼ 2. REST API
먼저 소개할 REST API를 만들 때는 데이터를 주고받는 기능들을 함께 넣어야 합니다. 예를 들어 로그인 요청을 할 때 아이디와 비밀번호의 데이터가 필요한 것처럼 말이죠. 먼저 클라이언트의 관점에서 보겠습니다. 클라이언트가 서버에게 ‘타임라인에 사진을 올리는 요청’을 보냈다고 가정하겠습니다.
이때 우리는 CRUD라고 불리는 데이터를 다루는 4가지 요소 기준으로 나눌 수 있습니다. 첫 번째로 C는 Create의 약자로 타임라인에 ‘올리는’ 요청을 뜻합니다. 두번째로 R은 Read의 약자로 타임라인에 사진을 ‘불러오는’ 요청입니다. 세번째로 U는 Update의 약자로 ‘바꾸는' 요청을, 마지막으로 D는 Delete로 ‘지우는’ 요청을 의미합니다. 개발자들은 데이터를 볼 때 항상 CRUD 관점으로 봅니다.
이렇게 타임라인의 CRUD 요청은 각각의 주소를 갖게 되고 이렇게 주소를 구성하게 되면 점점 더 많은 주소가 생겨나게 되는데 나중에는 1000개의 주소를 갖게 될 때는 관리가 어려워지겠죠? 그래서 사람들이 체계적인 API관리를 위해서 운동이 생겨나기 시작했고 이것을 우리는 REST API라고 부릅니다.
여기까지 잘 따라오고 계신가요? 그렇다면 두 번째 구조인 SOAP API 소개에 앞서, REST API의 데이터 포맷 종류인 JSON에 대해 알아보겠습니다.
◼ 2-1. JSON
비전공자는 새로운 단어들을 이해하기 위해서는 그전 단계에서 배운 단어를 한번 더 이해하고 넘어가는 시간이 필요합니다. 글을 작성하는 제가 잊지 않고 다시 상기시키기 위한 이유이기도 합니다. API는 클라이언트가 서버로 보내는 요청과 서버가 클라이언트에게 보내는 응답으로 이때 응답과 요청에 데이터가 담길 수 있게 ‘기능’을 같이 개발해야 한다고 앞서 설명했습니다. 기능에는 여러 가지의 형식이 있습니다.
이때 80개의 요청 형식이 다르면 80개의 형식에 대응하는 코드를 적어 줘야 합니다. 그래서 개발자들은 생각합니다. “바빠 죽겠는데 우리 유명한 형식으로 다 같이 쓰자”, 그렇게 해서 다양한 형식들 사이에서 현재 가장 유명한 형식은 JSON입니다.
JSON 형식으로 데이터들이 파일 안에 각각 들어가 마치 데이터들을 주고받는 주머니와 같습니다. 복잡하게 생각할 것 없습니다. “클라(클라이언트)와 서버는 요청과 응답을 주고받고 그때 필요한 데이터들을 JSON형식으로 주고받는다, 언제? REST API의 데이터를 주고받을 때 말입니다.
◼ 2-2. 아키텍처란?
또 한가지 짚고 넘어가야 할 용어는 아키텍처(Architecture) 입니다. REST API는 네트워크를 통해서 컴퓨터끼리 통신할 수 있는 아키텍처를 말하기도 합니다. 아키텍처란 영어 단어로써 ‘건축학’이라는 뜻을 가지고 있습니다. 건축학은 프로그래밍에 영향을 많이 끼친 학문이기 때문에 건축학 용어를 많이 사용하고 있습니다.
IT에서 아키텍처란 고객의 요구사항을 파악하여 이를 분석하고, 고객의 요구 사항을 충족시킬 수 있는 기초 소프트웨어를 설계하는 것입니다. 아키텍처는 소프트웨어를 구성하고 있는 가장 기초적이고 핵심적인 업무인 만큼 초보자들에게는 잘 맡기지 않습니다.
쉽게 예를 들어 체계적으로 건물을 설계하지 않아 태풍이나 지진과 같은 자연재해에 무너져 버리는 부실 공사를 같은 예를 들 수 있습니다. “REST API는 클라이언트와 서버 사이에서 통신할 수 있게 분리되어 있고, 클라이언트-서버라는 아키텍처를 만들 수 있게 해준다”로 이해하고 넘어가겠습니다.
◼ 3. SOAP API
두번째 대표 구조인 SOAP API는 REST API보다는 조금 더 복잡합니다. SOAP API를 이해하기 위해서는 먼저 ‘프로토콜(Protocol)’이란 개념부터 이해해야 합니다. 마찬가지로 비전공자가 작성하는 글인 만큼 개념 하나하나 설명하는 시간을 갖겠습니다.
첫번째로 프로토콜의 사전적 의미부터 살펴봅시다. 프로토콜은 디바이스와 디바이스 사이에서 데이터 통신을 원활하기 위해 필요한 통신 규약입니다. 이제 익숙해진 시간, 쉬운 예로 들어보겠습니다.
한국인과 아랍인이 있습니다. 이 둘은 지금 서로 커뮤니케이션이 필요한 상황입니다. 하지만 각자의 언어를 모르다 보니 둘은 전 세계에서 가장 많이 사용되는 언어인 영어로 커뮤니케이션을 하기 시작합니다. 수많은 사람이 소통을 하기 위해서는 공통되는 언어가 필요합니다.
이처럼 각자의 컴퓨터에서 여러 가지의 정보를 주고받을 때 서로에 대한 규칙에 대한 약속을 우리는 프로토콜이라고 부릅니다. 앞서 말한 REST API보다 복잡하다고 설명한 이유는 이러합니다. SOAP는 그 자체로 프로토콜이며, 메시지 전송 등에 있어서 REST보다 더 많은 표준이 정해져 있기 때문에 더 복잡하다고 말할 수 있습니다.
◼ 3-1. XML
위에 설명한 REST API는 대표적으로 JSON 형식을 가지고 있는 것과 같이 SOAP API는 XML 형식만 갖고 있습니다. 그렇다면 XML은 무엇일까요? XML(Extensible markup language)은 해석하면 확장 마크업 언어라는 뜻을 가지고 있습니다. 그럼 여기서 또 마크업(Markup)이란 무엇일까요? 이 모든 것을 이해하기 위해서는 첫번째로 웹 구성을 먼저 알아야 합니다. 웹 사이트에서 제공되어 있는 표준 기술은 HTML, CSS, JavaScript 이 세가지로 정리할 수 있습니다.
✔ HTML, CSS, JavaScript, 마크업 ❔
가장 먼저 HTML의 시작은 유럽의 ‘입자 물리 연구소’였습니다. 당시 연구소에서 일하던 ‘팀 버너스 리’는 서로 직원들이 수많은 정보들을 주고받을 때 하나의 문제를 발견합니다. 서로 다른 운영체제들을 사용하고 있기 때문에 각각 같은 OS에서만 호환이 되는 파일이라면 서로 파일을 열지 못한다는 불편함이 생긴다는 것입니다.
그래서 팀 버너스는 이를 해결하기 위해 일정한 형식, 즉 HTML 형식으로 작성한 문서를 제안합니다. 그래서 운영체제에 상관없이 HTML 브라우저만 있으면 모두 웹사이트에 접속하여 동일한 정보를 볼 수 있도록 고안합니다.
이를 통해 많은 사람들이 HTML을 이용하여 서로 많은 정보를 주고받기 시작하는데 이때 사람들은 이런 생각이 들기 시작합니다. “HTML은 정보 전달에만 초점이 되어 있어, 여기서 디자인적 요소가 추가 되었으면 좋겠는데…"라는 생각! 그래서 훗날에는 HTM에 디자인 요소를 추가로 넣을 수 있는 코드인 CSS(Cascading Style Sheets)가 만들어졌습니다.
이렇게 코드가 각자 분리가 되었고 정보를 수정하고 싶으면 HTML 코드만 수정하고, 디자인만 수정하고 싶으면 CSS코드만 수정하면 되는 편리함을 얻게 됩니다. 이렇게 HTML과 CSS를 합쳐서 ‘퍼블리싱 작업’이라고 표현하고 사람들은 ‘퍼블리셔’, ’마크업’이라는 말로 표현을 합니다.
더 나아가 또 다른 기능들을 원하는 사람들이 생겨나고 HTML과 CSS로는 해결하기 힘든, 예를 들면 “API 요청을 주고받고 싶어”라는 요청들을 해결하기 위해서는 프로그램 언어가 필요한데 이 프로그램 언어를 바로 ‘JavaScript(혹은 JS)’라고 부릅니다. 자, 이렇게 우리는 벌써 웹을 구성하고 있는 세 가지 표준 기술과 마크업이라는 단어의 뜻을 빠르게 훑어봤습니다. 이제 XML은 HTML과 CSS의 언어가 합쳐진 마크업이라는 뜻까지 이해할 수 있게 됐습니다.
✔ 에필로그
여기까지 API에 대한 궁금증으로 출발해 REST API와 SOAP API, 이를 다루는 데이터 형식 JSON과 XML, 그리고 아키텍처와 프로토콜 유형에 대해 차례로 알아봤습니다. 비전공자이다 보니 어려운 단어들 보다 최대한 기본적인 단어 풀이 위주로 이해하기 쉬운 예를 들어 용어를 해설해봤습니다. IT용어에 대한 샘솟는 궁금증을 비전공자의 입장에서 풀이하는 시간을 계속 마련해보려 합니다. 곳곳에 숨어 계시는 우리 비전공자 여러분, 오늘도 역시 파이팅! 다음 이야기로 다시 만나요!