[10분 테코톡] 🐯 심바의 RESTful 정리

REST란?

분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처

- MDN -

 

네트워크 리소스를 정의하고 처리하는 방법을 설명하는 일련의 원칙을 기반으로 하는 아키텍처 스타일

-Service Architecture-

 

REST에 대한 원칙은 2000년동에 로이 필딩(Roy Fielding)의 박사학위 논문에서 최초로 소개되었다. 로이 필딩은 HTTP의 주요 저자 중 한 사람으로 웹(HTTP)가 제대로 사용되지 못하는 점을 안타까워하며 HTTP의 장점을 최대한 활용할 수 있는 아키텍처로써 REST를 발표하였다. 그래서 REST 원칙은 HTTP를 잘 활용하기 위한 원칙이라고 할 수 있다.

 

이 REST에 대한 원칙을 준수했을 때, 그 시스템이 RESTful 하다 라고 한다. REST는 REpresentational State Transfer 의 약자로, 직역하자면 표현적인 상태 전달이다. 의역하자면 자원(리소스)의 표현에 의한 상태(정보) 전달이라는 뜻을 가지고 있다. 여기서 자원의 표현은 REST의 가장 큰 특징 중 하나이다.

 

예시를 통해 알아보자면 아래와 같이 URI만 보고도 어느정도 예측할 수 있다는 것이다.

/courses/front	프론트엔드 과정에 대한 정보
/courses/back	백엔드 과정에 대한 정보
/courses/front/crews/simba	심바에 대한 정보

이처럼 리소스를 URI에 표현해서 주고받을 정보에 대해 어느정도 예측할 수 있다.

 

REST API에서 URI는 어떤 구조를 가지고 있을까?

URI로 테이블을 만들어본다면, 테이블 전체에 해당하는 부분을 Collection (위 표에서 빨간 글자) 행하나의 부분 혹은 객체를 Document라고 한다. (위 표에서 파란 글자) Collection은 일반적으로 객체들의 집합이기 때문에 복수명사를 사용한다. Document는 이 집합들 중 객체를 구분할 수 있는 값으로 위에서는 title을 사용했는데 일반적으로는 id를 많이 사용한다. URI는 이러한 Collection과 Document의 조합으로 이루어져 있다. 주의할 점으로는 URI에는 동사를 사용하지 않는 다는 점이다.

 

/courses/back/coaches/append

/courses/front/crews/remove

새로운 코치가 들어오거나 크루가 크루에서 나가는 경우에 대해 처리하기 위해서 이런한 표현을 사용하지 않는 다는 것이다. REST API에서는 이러한 처리를 위해, 즉 자원에 대한 행위에 대해서 HTTP Method를 사용한다. 일반적으로 데이터 처리에는 4가지 방법이 있다.

 

Create	➔	POST
Read	➔	GET
Update	➔	PUT or PATCH
Delete	➔	DELETE

Create, Read, Update, Delete 이것을 줄여 CRUD라고 부른다. HTTP Method에서는 이러한 기능을 위해서 각각 POST, GET, PUT 또는 PATCH, DELETE를 사용한다.

Read(조회) - GET

GET    /courses

GET    /courses/front

조회하기 위해서는 URI에 조회하고자 하는 Collection과 Document를 명시해주면 된다. 일반적으로 Collection만 명시할 경우 해당 Collection에 대한 전체 정보를, Document까지 명시할 경우에는 Document에 대한 정보를 조회할 수 있다.

 

Create(생성) - POST

POST    /courses/back/coaches

body    { nickname: neo}

생성할 때는 어떤 객체를 생성할 것인지에 대한 내용이 필요하다. 이 내용을 body에 담아서 표현한다.그래서 위와같이 백엔드 코치 집합에 네오라는 닉네임으로 가진 코치 객체 생성을 나타낼 수 있다.

Update(수정) - PUT

PUT    /courses/front/coaches

body    { id: 1, nickname: makerjun}

수정할 때는 어떠한 정보를 수정할 것인지에 대한 정보가 필요하다. 이 내용도 body에 담아서 표현한다. 위와같이 표현하면 프론트엔트 코치 집합 중 첫번째 코치 닉네임을 메이커준으로 수정한다는 것을 나타낼 수 있다.

Delete(삭제) - DELETE

DELETE    /courses/front/crews/bren

삭제하고 싶을 때에는 URI의 Collection에서 삭제하고자 하는 Document만 명시해두면 된다. 

 

하지만 이 네가지 방식만의 URI만으로 모든것을 표현하는데 어려움이 있다. 그 예로는 로그인과 로그아웃이 있다. 로그인의 경우 Collection을 users로 사용하고 아이디, 패스워드가 필요하니까 이 것을 body에 표현해서 POST 요청을 보내면 될까? 이 표현은 회원가입처럼 보인다. 로그아웃의 경우에도 DELETE요청으로 보내고 /users/{id} 로 한다면 회원탈퇴 같이 보인다. 그래서 이런 부분은 /login, /logout으로 예외적으로 처리하기도 하는데 이 API는 틀린 것일까? REST는 처음에 말한 것처럼 아키텍처 스타일이다. 그렇기 때문에 REST의 모든 원칙들을 지키지 않는다고 해서 API가 틀린것은 아니다. 물론 모든 것을 준수한다면 좋겠지만 어려움이 있다.

---

참고

https://www.youtube.com/watch?v=NODVCBmyaXs&ab_channel=%EC%9A%B0%EC%95%84%ED%95%9C%ED%85%8C%ED%81%AC