REST API

REST API는 프론트엔드 개발자, 백엔드 개발자 모두 꼭 알고 있어야 하는 개념이다.

나 또한 정말 많이 들었는데, 그 개념이 아리송한 부분이 있어서 공부를 하다가

초보자인 나에게 아주 쉽게 다가온 유툽 영상이 있어서 내용을 까먹지 않기 위해 정리해보려고 한다.

 

 

들어가기 앞서..

REST API는 정보들이 주고받아지는 데 있어서 개발자들 사이에 널리 쓰이는 일종의 형식이라 할 수 있다.

 

예를 들어 우체국에 가면 송장들이 마련되어 있고, 사용자들은 그걸 채워넣기만 하면 되는 것처럼 REST API도 어떠한 기술이나 제품이 아닌 형식이기 때문에 어떤 프로그래멍 언어를 쓰든, 어떤 프레임워크를 쓰든 REST API라는 형식에 맞춰 기능을 만들어내면 되는 것이다.

 

그럼 일단 API라는 용어부터 간단하게 알아보자.

 

 

API가 뭐야?

어떤 기계를 만들면, 사용자가 그 기능들을 전부 활용할 수 있도록 제어장치를 마련해야 한다.

 

예를 들어 TV를 생각해보자.

TV를 키고 끄거나 채널 변경 또는 음량 조절을 할 수 있는 제어장치인 리모콘이 있다.

같은 이유로 자판기에는 버튼들이 있고, 컴퓨터에는 키보드와 마우스가 있다.

 

이러한 것들을 인터페이스(Interface)라고 한다.

즉, 인터페이스는 기계와 인간 간의 "소통창구"인 것이다.

사용자가 명령을 넣는 것 뿐 아니라, 그 결과와 정보들을 받아오기 위한 TV의 스크린, 컴퓨터의 모니터 또한 이 인터페이스에 속한다.

 

그럼 소프트웨어 영역에서 생각해보자.

 

컴퓨터나 스마트폰을 켜면 사용자들이 프로그램이나 사이트, 앱을 원하는대로 제어하고 정보를 볼 수 있도록

버튼, 스크롤바, 슬라이더, 브라우저 창 등 소프트웨어적인 장치들이 마련되어 있다.

 

다들 한번쯤은 "UI"라는 것을 들어봤을 것이다.

이것이 바로 소프트웨어와 인간의 소통을 위한 사용자 인터페이스(User Interface)인 것이다.

 

하지만 IT세계에서는 우리 눈에 보이지 않는 영역들이 더 많다.

기계과 기계, 소프트웨어와 소프트웨어 사이에서도 수많은 요청과 정보 교환이 이뤄지고 있다.

이들 사이에서도 소통할 수 있는 창구가 필요할 것이다.

 

예를 들어 기상관련 정보가 관리되는 기상청 서버를 생각해보자.

포털이나 날씨 관련된 서비스를 제공하는 다양한 웹사이트들, 앱들이 이 기상청 서버로부터 실시간으로 날씨 정보를 요청해서 받아간다.

 

미리 작성된 소프트웨어를 통해서 이 기상청 서버와, 서버들 또는 앱들 사이에 정보들이 요청되고 전송될 것이다.

이때 이 정보들을 요청하는 지정된 "형식"이 있어야 하는 것이다.

 

위 그림과 같이 "날짜, 지역, 조회할 내용을 어떠한 형식으로 표시해서 주소로 정보를 요청하면 이렇게 답이 올거야"라는 공개된 메뉴얼이 있다면, 누구든 이걸 참조해서 기상청 정보를 활용하는 소프트웨어를 만들 수 있을 것이다.

 

이처럼 소프트웨어가 다른 소프트웨어로부터 지정된 형식으로 요청, 명령을 받을 수 있는 수단을 API(Application Programming Interface)라고 한다.

 

API에 대해 이해를 어느정도 했으니, 그럼 이제 그 중에서도 REST API가 뭔지 알아보자.

 

 

REST API는 뭔데?

REST API란 단순히 RESTful한 API를 말하며 일련의 특징과 규칙 등을 지키는 API를 말한다.

2000년에 Roy Thomas Fielding이 쓴 논문에서 처음으로 이 개념이 등장했다.

 

배달 앱에서 서버에 주문을 넣는 등 서비스들에서 오늘날 널리 사용되는 것이 REST란 형식의 API이다.

 

REST하다..?

REST의 가장 중요한 특성은 각 요청이 어떤 동작이나 정보를 위한 것인지를 그 요청의 모습 자체로 추론이 가능하다는 것이다.

 

만들고자 하는 서비스에서 기능 자체만 중요하게 생각한다면 REST고 뭐고 생각할 필요 없이 동작만 하게 만들면 그만이지만,

문제는 서비스를 개발자 혼자 만드는게 아니라는 것이다.

당장은 혼자 개발을 할 지라도  나중에 이 일을 인계받을 개발자나, 이 API를 사용해서 다른 제품을 만들 개발자들은 굉장히 일하기 힘들어 질 수도 있다....^^

 

따라서 RESTful하게 만든 API는 요청을 보내는 주소만으로도 대략 이게 뭘 하는 요청인지 파악이 가능하다.

예를 들어 학원 시스템에 대한 REST API를 만든다고 하면, 다음과 같이 만들 수 있을 것이다.

요청 주소	요청의 의미
https://(도메인)/classes	학원의 반들 목록
https://(도메인)/classes/2	학원의 반들 중 2반의 정보
https://(도메인)/classes/2/students	2반 학생들의 정보
https://(도메인)/classes/2/students/15	2반 학생들 중 15번째 학생의 정보
https://(도메인)/classes/2/students?sex=male	2반 학생들 중 남학생들의 정보

 

이렇게 자원을 구조와 함께 나타내는 형태의 구분자를 "URI"라고 한다.

 

이때 조회작업 뿐만 아니라, 정보를 새로 넣거나 수정 및 삭제하는 작업 또한 필요할 것이다.

이를 통틀어서 CRUD라고 한다.

• CREATE (생성)
• READ (조회)
• UPDATE (수정)
• DELETE (삭제)

 

서버에 REST API로 요청을 보낼 때는 HTTP(HyperText Transfer Protocol)란 규약에 따라 신호를 전송한다.

우체국에서 택배를 부칠 때 일반우편, 등기 등 다양한 방식이 있듯이 이 HTTP로 요청을 보낼 때도 여러 메소드가 있다.

• GET
• POST
• DELETE
• PUT
• PATCH

여기서 소포가 편지보다 더 많은 것을 담을 수 있듯이,

POST, PUT, PATCH에는 body라는 주머니가 있어서 GET, DELETE보다 많은 정보들을 비교적 안전하게 감춰서 실어보낼 수 있다.

 

이것들의 기능이 특정 용도에 제한되어 있지는 않지만, 누구든 각 요청의 의도를 쉽게 파악할 수 있도록 RESTful하게 API를 만들기 위해서는 목적에 따라 구분해서 사용해야 한다.

GET	조회
POST	새로운 정보 추가
PUT	변경, 정보를 통째로 변경할 때
PATCH	변경, 정보 중 일부를 특정 방식으로 변경할 때
DELETE	삭제

 

결국 REST API란, HTTP 요청을 보낼 때 어떤 URI에 어떤 메소드를 사용할지 개발자들 사이에 널리 지켜지는 약속이다.

 

이는 이미 말했듯, 형식이기 때문에 기술에 구애받지 않는다.

앱을 만들든, 웹사이트를 만들든 그것들을 어떤 언어로 뭘 써서 만들든 거기에 소프트웨어간 HTTP로 정보를 주고받는 부분이 있다면

이 형식, 규칙들을 준수해서 RESTful한 서비스를 만들 수 있는것이다!

 

 

RESTful하게 API 디자인하기

• 리소스와 행위를 명시적이고 직관적으로 분리한다.
  • 리소스는 URI로 표현되는데 리소스가 가리키는 것은 명사로 표현되어야 한다.
  • 행위는 HTTP Method로 표현한다.
• Message는 Header와 Body를 명확하게 분리해서 사용한다.
• API 버전을 관리한다.
• 서버와 클라이언트가 같은 방식을 사용해 요청하도록 한다.
•  

 

 

 

Reference

 

얄팍한 코딩사전-REST API가 뭔가요?