REST API란 뭘까? 많이 들어는 봤는데 개념이 모호하다.
지금부터 이에 대해 간단히 알아보자. 시작하기 전 이 글은 진정한 의미의 REST API가 아닌 개발자들이 일반적으로 알고 쓰는 수준의 REST API 이다.
REST API는 정보들이 주고받아지는 데 있어서 개발자들 사이에 널리 쓰이는 일종의 형식이다. 간단히 예를 들어보자.
우체국에 가면 이런 송장들이 마련되있다.
이용자들은 이를 형식에 맞게 채워넣는다. (이름은 홍길동, 전화번호는 010-xx...)
이 과정을 더 깊이 있게 얘기해보자.
어떠한 형식(Form)이 있으면 사용자들은 이에 맞게 양식을 채워나간다. 즉, 어떤 프로그래밍 언어를 사용하든, 어떤 프레임워크를 쓰든, 어디에 소프트웨어를 만들든 간에 개발자는 특정 형식(Form)에 맞춰서 기능을 만들어내면 되는 것이다.
그 전에, API가 뭔지 간단히 알아보자.
API(Application Programming Interface)
어떤 기계를 만들면, 사용자가 그 기능들을 전부 활용할 수 있도록 제어장치를 마련해야한다.
예를 들어, TV는 사용자가 전원을 키고끄고, 채널 선택, 음량 조절 등의 다양한 기능을 할 수 있어야 한다. 이러한 기능을 제공하기 위해 리모컨이라는 제어장치를 사용자에게 제공한다.
이런 것들을 인터페이스(Interface)라고 부른다. 우리가 리모컨을 사용하여 TV(기계)를 제어하는 것을 생각해보자. 인터페이스는 기계와 인간간의 소통창구라 할 수 있다.
더 나아가 사용자가 명령을 넣는 것 뿐만 아니라, 그 결과와 정보들을 받아오기 위한 TV의 스크린, 컴퓨터의 모니터 또한 이 인터페이스에 속한다.
자, 이제 소프트웨어의 영역으로 들어가보자. 컴퓨터나 스마트폰을 켜보면 사용자들이 프로그램이나 사이트, 앱을 원하는대로 제어하고 정보를 볼 수 있도록 버튼, 스크롤바, 브라우저 창 등이 소프트웨어적 장비가 존재하는데 이를 UI(User Interface)라 한다. 말 그대로 소프트웨어와 사용자의 소통을 위한 장치이다.
하지만, 이러한 IT 세계에서는 우리 눈에 직접 보이지 않는 영역들이 더 많다. 기계와 기계, 소프트웨어와 소프트웨어 사이에도 수 많은 요청과 정보 교환이 이뤄지고 있다. 이들 사이에서도 소통할 수 있는 창구가 필요한 것이다!
다수의 클라이언트가 하나의 특정 서버에서 데이터를 주고 받는 상황을 생각해보자. 미리 작성된 소프트웨어를 통해서 둘 사이에 데이터들이 요청되고 전송되는 것이다. 그러기 위해선 어떤 것이 필요할까? 바로 정보들을 요청하는 지정된 형식 즉, 특정 형식이 필요한 것이다. 사용자가 계좌 잔액 조회를 하기 위해 서버에 요청을 보내면 서버는 특정 형식에 맞춰 고객명, 출금 가능 금액 등을 넣어서 클라이언트에게 전송하면 클라이언트에게 어떻게 응답이 올 것이라는 공개된 메뉴얼이 있으면 누구든 이를 활용한 소프트웨어를 만들 수 있을 것이다.
이처럼 소프트웨어가 다른 소프트웨어로부터 지정된 형식으로 요청, 명령을 받을 수 있는 수단을 API(Application Programming Interface)라 한다.
참고
꼭, 네트워크 상에서만 API가 있는 것은 아니다. 로컬 프로그램인 브라우저는 Web API를 통해 자바스크립트로 부터 특정 동작들을 지시받기도 하며, 윈도우에는 개발자들이 프로그램을 개발할 때 시스템이나 하드웨어에 대한 세세한 지식이 없어도 지정된 명령어로 윈도우에서 동작을 수행할 수 있도록 하는 Windows API도 제공한다. (이 함수를 넣으면 윈도우가 이렇게 해준다. 같은 것)
REST API
이제 API란게 뭔지 분명히 이해됬을 것이다. 그럼 그 중에서 REST API가 뭔지 알아보자.
프론트엔드 웹에서 서버에 데이터를 요청하거나 배달 앱에서 서버에 주문을 넣거나 하는 등 이러한 서비스들에서 오늘날 널리 사용되는 것이 바로 REST API이다. 과거의 SOAP이란 복잡한 형식을 대체한 것이다.
REST의 가장 중요한 특성은 각 요청이 어떤 동작이나 정보를 위한 것인지를 그 요청의 모습 자체로 추론이 가능하다는 것이다.
만들고자 하는 서비스에서 기능 자체만 중요하게 생각한다면 REST가 필요없이 동작만 하게 만들면 그만이다.
그러나, 문제는 서비스는 혼자 만드는 것이 아니라 여러 명의 개발자들이 함께 만든다는 것에 있다.
REST의 특성 지키지 않고 자기 멋대로 요청 모습을 작성한 API를 사용해서 다른 제품을 만들 개발자들은 요청의 모습을 개떡같이 만들어놓으면 일하기 싫어질 것이다..
RESTful하게 만든 APU는 요청을 보내는 주소만으로도 대략 이게 뭘 하는 요청인지 파악이 가능하다.
학원 DB에게 정보를 보내달라는 요청을 하는 상황이다.
htttp://(도메인)/classes
- 학원 전체 반을 조회한다는 뜻으로 추측할 수 있다.
htttp://(도메인)/classes/2
- 학원 전체 반 중 2반만 조회한다는 뜻으로 추측할 수 있다.
http://(도메인)/classes/2/students?sex=male
- 학원의 2반 남학생들을 조회한다는 뜻으로 추측할 수 있다.
참고
자원(Resource)을 구조와 함께 나타내는 이런 형태의 구분자를 URI라 한다.
그러나, 단순히 이러한 조회 기능뿐만 아니라 삭제/수정/생성 기능들도 필요하다.
이 기능들을 통틀어서 C.R.U.D라 부른다.
C.R.U.D : Create(생성) Read(조회) Update(수정) Delete(삭제)
서버에서 REST API로 요청을 보낼 때는 HTTP란 규약에 따라 신호를 전송한다. 앞의 예시를 더 생각해보자. 우체국에서 뭘 부칠 때 일반우편, 등기, 택배 등 다양한 방식이 존재한다. 마찬가지로 이 HTTP로 요청을 보낼 때에도 여러가지 메소드가 존재한다. 이에 대한 설명은 HTTP 메소드를 참고하자.
