[Spring] 쉽게알아가는 REST API , RESTful API

REST ? RESTful?

---

웹을 공부하면서 가장 많이 들었던 단어 중 하나였다. 공공데이터 포털을 가도 REST API가 나오고, 과거에 교수님께서 "REST API 한번 개발해봐야 한다. "라고 했던 말들이 기억에 스친다. "도대체 REST가 뭐고 RESTful 은 또 뭐냐?" 이러한 생각을 가지고 이 블로그를 들어왔다면, 오늘의 맛집 탐방 성공이다. 🍜🍜

 

API 란 ?

---

REST 든 RESTful 이든  API를 꾸미는 형용사다. 즉 API라는 놈을 모르면 말짱 꽝이니 정의부터 확실히 하고 가자.

API는 Application Programming Interface의 약자로 쉽게 말하면... 인터페이스다! (이게 끝이냐!!🤬🤬)

우리가 문서작업을 하다가 복사를 하고 싶다면, ctrl+z를 누를 것이다. 컴퓨터 내부에서 ctrl+z가 어떻게 돌아가는지는 모르겠지만, 어쨌든 ctrl+z라는 원칙으로 부탁하면, 그 결과로 알아서 복사를 해준다. 또한 대부분의 키보드 인터페이스들이 언더 국 룰로 ctrl+v를 실행했을 때, 복사 기능을 수행해준다. 원하는 방식으로 결과를 받을 수 있도록, 요청을 약속한 것이다. 이것이 인터페이스의 개념이며, API 개념의 끝이다.

 

REST API란?

---

REpresentational State Transfer의 약자로 (왜 첫 글자만 두 개 따...?)  웹의 장점을 최대한 활용할 수 있는 아키텍처이다.

이해를 돕기 위해 본 맛집의 MSG를 첨가해보자. 여기서부턴 필자의 소설의 영역이 어느 정도 포함되어있으니, 이해하는데 초점을 두자.(남한테 꼬투리 잡혀도 난 모름!!)

 

REST가 나오게 된 이유는 중구난방인 API 때문이 아닐까 하고 추측한다. 때는 대 웹 API전국시대, 중구난방의 제멋대로인 API들을 보며, 각 API마다 형식이 달랐을 것이다. 해당 API를 쓰기 위해서 항상 문서를 읽게되는 번거로움을 겪게 되는 것이다. 이러한 불편함에 빡쳐 인터페이스를 정형화하고 구조화 한게 REST API다.

즉, 웹에서 누가 봐도 편하게 쓸 수 있게 API들의 약속을 구조화한 것이라고 이해하면 좋을 것 같다.

 

REST의 구조

---

REST API는 웹에서 쓰기위해 만들어진 아키텍처다. 즉, 요청을 어떻게 보내면 사람들이 잘 알아먹을까? 에 대해 하는 얘기들이며, 구성을 나는 다음과 같이 요약했다.

 

REST = 행위  + 자원 +표현 

 

> 쉬운 인간의 언어 :D

REST = (어떤 방식으로) + (무엇을 요청할 것이며) + (그래서 뭐 줄 건데?)

 

1) 행위(HTTP Method)

웹에서 하는 행위는 딱 CRUD 4가지뿐이다.  요청할 때, 이 4가지를 구분 지어 보내달라는 것이 행위의 핵심 골자다.

 

행위 (Method)	역활(Role)	비고
POST	해당 리소스를 생성함	Create
GET	해당 리소스를 조회함	Read
PUT	해당 리소스를 수정함	Update
DELETE	해당 리소스를 삭제함	Delete

표를 보면 알겠지만, 정말 CRUD에 딱 매칭이 되도록 쪼개 놨다. 즉, 요청을 보낼 때부터 요구하는 행위가 무엇인지 요청 방식을 통해 인지할 수 있도록 설계되었다.

 

 

2) 자원

위의 행위가 되는 대상(Resource)라고 생각하면 된다.  '삽입이든 수정이든 뭐든 요청은 할 건데... 그래서 뭐를 요청할 건데?'에 대한 답변에 해당하는 부분이다. 즉, 대상이 되는 자원에 대한 내용을 명시해주는 부분이라고 할 수 있다. 

자원은  URI를 통해서 표현하게 되는데, 이 URI 작성엔 아래와 같은 디자인 가이드가 있다.

 

• 자원은 명사로 표현한다.
• 확장자를 표시하지 않는다.
• 소문자를 쓴다.
• _(밑줄)은 쓰지 않고 -(하이픈)은 쓴다.
• /(슬래쉬)로는 계층 관계를 나타내며, 마지막 문자로 /(슬래쉬)를 쓰지 않는다

 

cf) URL? URI? 🤔🤔

이쯤 되면, URL과 URI 가 슬슬 헷갈릴 때라고 생각해서 넣었다. 

> URL은 Uniform Resource Locator의 약어로 위치를 의미한다. 즉, 정확한 자원의 위치에 대한 용어이다.

> URI는 Uniform Resource Identifier의 약어로 식별자를 의미한다. 즉, 자원에 대한 식별 용어이다.

REST API 디자인 가이드에 따라 URI는 확장자를 사용하지 않는다. 해당 자원에 대한 이야기를 하는 것이 URI이지, 그 자원에 위치에 대한 얘기는 중요하지 않다는 의미이다. (그래서 URL보다 URI가 더 포괄적인 범위이다.) 

 

3) 표현

응답에 대한 내용이라고 보면 좋을 것 같다. 행위와 자원을 정갈하게 나눠서 '주세요~' 하고 요청을 했다면, 그에 맞게 응답도 정갈하게 보내준다는 내용이다. REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등으로 나타내어질 수 있다. 대부분은 JSON을 통해 데이터를 주고받는게 일반적이다.(xml으로도 주로 주고 받지만, 나는 JSON만 써봤다. 그만큼 JSON으로 많이 주고 받는 것 같다.) 

 

 

 

💡REST API의 특징💡

---

이러한 REST API에는 특징이 있는데, 이해를 돕기 위해 순서를 약간 조정했다. 특징은 다음과 같다.

 

1) Stateless(무상 태성) 

HTTP 프로토콜은 Stateless Protocol이므로 REST 역시 무상 태성이다. 즉, 세션이나 쿠키를 연결해두고 있는 녀석이 아니다. 한 번의 요청이 지난 뒤에 클라이언트가 있는지 없는지 서버는 별로 관심이 없다. 이렇게 되면, 클라이언트가 있는지 없는지 눈치 보는데 신경을 안 쓰기 때문에(=Client Context를 관리를 안 하기 때문에) 서버의 부담이 줄어든다.

 

2) Cacheable(캐시 처리 가능)

기존 인프라를 이용하기 때문에, 얘도 캐싱을 적용할 수 있다는 말이다. 즉 대량 요청에 효율적인 처리를 할 수 있다는 의미이다.

 

3) Uniform Interface(일관된 인터페이스)

통일된 URI 덕분에 요청이 플랫폼을 가리지 않을 수 있게 된다. 기술의 종속받지 않음을 의미하며, Http를 사용하는 어떠한 플랫폼에서든 사용할 수 있다는 의미이다.

 

4) Self-Descriptiveness(자체 표현)

위의 디자인 가이드를 잘만 따라준다면, URI만 보고도 쉽게 의도를 파악할 수 있다. 즉, 이해하기 쉬운 자체 표현 구조를 지녔다.

 

5) Client-Server Architecture (서버-클라이언트 구조)

자원을 가진 서버와 자원을 요청하는 클라이언트 구조를 말한다. 서버 쪽에서는 API를 제공하고, 클라이언트가 인증, 세션정보 등을 직접 관리하게 끔 분리한다. 이로 인해 서로 간의 의존성을 낮출 수 있다.

 

6) Layered System(계층 구조)

이건 제대로 찍어먹어보지 않아서, 가슴에 크게 와닿지는 않는다. Rest API의 서버는 다중 계층으로 구성될 수 있으며 순수 비즈니스 로직을 수행하고 그 앞단에 보안, 로드밸런싱, 암호화, 사용자 인증 등을 추가하여 구조상의 유연성을 줄 수 있다. 또한 로드밸런싱, 공유 캐시 등을 통해 확장성과 보안성을 향상할 수 있다.

 

 

Ok... 그래서 RESTful API가 뭔가요?

---

미(美)를 명사로 하면 beauty라고 한다. 이를 형용사로 표현하면 ful이라는 접미어가 붙어서, 아름다운 이란 뜻을 가진 beautiful 이 된다. 똑같다. 그냥 형용사다. (거창한 거 기대하지 마라 진짜 이게 전부다. 이것도 약어인 줄 알고 functional ultimate language 이런 건가? 하고 생각했던 건 안 비밀😳)

 

REST를 지키지 않는다고 해서 컴파일 에러가 날까?  도메인을 받을 수 없을까? 그건 아니다. 단, 우리가 소니 노트북을 샀다고 갑자기 복사하기가 ctrl+k 가 된다면, 불편함의 문제지, 기능적 결함이라고 할 수는 없다.말 그대로 가이드 일 뿐이다. 그런 의미에서 권고 가이드를 잘 따르고, 준수하는 API들을 "RESTful 하다"라고 표현하는 것이다. 

 

 

 

📃 References]

• https://www.lostcatbox.com/2021/01/19/basic-api/
• https://meetup.toast.com/posts/92