REST, RESTful 은 무엇일까?

 

회사에서 Stoplight (API 모델링, API 문서, API 모의 테스트(Mocking)에 사용하는 플랫폼) 세미나에 참여했다.

 

세미나 전에 미리 REST에 대해 공부를 해오라는 지시?가 있어서 공부를 했고 공부 중 정리한 내용을 기록할까 한다.

 

 

---

 

 

 

우선 REST는 무엇을 줄인 말일까?

REpresentational : 표현
State: 상태
Transfer: 전달

 

이를 한글로 풀어보자면 "어떤 자원(백엔드의 자원이라고 생각하면 될까?) 의 표현을 가지고 상태를 전달한다" 로 해석할 수 있을 듯 하다.

 

이때 표현은 무엇이고 상태를 어떻게 전달할까? 라고 생각해봤을 때, 일반적으로는

 

표현은 URI 이고 상태의 전달은 HTTP Method 라고 보면 될 것 같다.

 

먼저 URI에 대해 알아보자.

 

 

 

 

자원의 표현 - URI

---

id	name	body
1	John	~~~
2	Zach	~~~

 

예시로 데이터를 위와 같이 표시했다.

 

위 데이터에서 행 하나 (객체) 를 Document라고 하며,

 

행들의 집합을 Collection이라고 한다.

 

그리고 나는 Collection의 이름을 class로 정했다. 그렇다면 각 행의 URI는 다음과 같이 표시할 수 있을 것이다.

 

• /class/1
• /class/2

 

 

 

자원의 행위 - HTTP Method

---

흔히 생성하고 (Create) 읽고 (Read) 수정하고 (Update) 삭제하는 (Delete) 행위를 줄여서 CRUD라고 부른다.

 

이러한 행위를 HTTP Method에서는 각각 POST, GET, PUT or PATCH, DELETE로 사용한다.

 

각각에 대해 살펴보자.

 

 

• Read(조회) - GET

❗ 조회를 하기 위해서는 URI에 조회하고자 하는 Collection과 Document를 명시해준다.

- GET /class ⇒ Collection만 명시할 경우 해당 Collection에 대한 전체 정보를 가져온다.

- GET /class/1 ⇒ Document까지 명시해줄 경우 해당 Document에 대한 정보를 가져온다.

• Create(생성) - POST

❗ 생성을 할 때에는 어떤 객체를 생성할 것인지에 대한 정보를 함께 보내줘야 하며, 이를 body에 담아서 표현한다.

- POST /class

- body { name : Peter, body: ~~~ }

• Update(수정) - PUT

❗ 수정을 할 때에도 어떤 객체를 수정할 것인지에 대한 정보를 함께 보내줘야 하며, 이를 body에 담아서 표현한다.

- PUT /class

- body { id: 1, name: James, body: ~~~ }

• Delete(삭제) - DELETE

❗ 삭제를 할 때에는 URI에 Collection에서 삭제하고자 하는 Document만 명시해주면 된다.

- DELETE /class/1

 

단, 위의 조건만으로 모든 API를 표현하는 것에는 어려움이 있다.

 

그렇지만 REST는 일종의 스타일이므로 REST의 모든 원칙을 지키지 않는다고 해서 API가 틀린 것은 아니라고 보면 될 둣 하다.

 

 

 

---

 

 

자, 그렇다면 RESTful하다는 말은 무엇이라고 생각하면 될까?

 

~~ful 의 접미사를 생각해본다면... REST라는 스타일을 잘 만족한다? 라고 생각하면 될 듯 하며 좀 더 사전적인 말로는

 

"REST라는 아키텍쳐 스타일의 조건을 만족하는 시스템"으로 설명할 수 있을 것이다.

 

REST라는 아키텍쳐 스타일의 조건에는 여러가지가 있는데 그 중 몇 가지만 적어두려고 한다.

 

1. Client - Server

• Client가 Server에게 Request를 보내고, Server가 Client에게 Response를 보내는 구조
• 서버는 API 제공과 제공된 API를 이용하여 비지니스 로직을 처리하거나 저장하는 역할
• 클라이언트는 사용자 인증이나 Context (세션, 로그인 정보) 등을 관리하는 역할

2. Statelessness

• 클라이언트와 서버의 통신에는 상태가 없어야 한다. (세션, 이전 상황.. 등)
• 모든 요청은 필요한 모든 정보를 담고 있어야 한다.

3. Cacheable

• 서버의 응답 메시지는 캐싱(저장 후 재사용)될 수 있다.

 

 

---

 

 

 

REST에 대해 다소 순서 없는 느낌으로 정리했는데, 미래의 내가 다시 이 글을 봤을 때 '뭔 헛소리지'라는 말만 안나왔으면 좋겠다...!

 

혹여 이 글을 보는 사람이 있다면 피드백은 환영입니다~

 

 

 

 

 

참조 URL
https://www.youtube.com/watch?v=xY7cpMuWh4w&t=653s
https://www.youtube.com/watch?v=NODVCBmyaXs