👀 이론

REST, REST API, RESTful API 본격 알아보기

김비니 2025. 1. 2. 10:53

들어가며

안녕하세요, 이젠 누군지 다들 아실법한 풀스택 개발자 비니입니다.

마이크로서비스 아키텍처가 떠오르고, 클라우드 시스템이 발전하면서

REST 구현 능력에 대한 언급이 자주 등장하고 있는 것 같아요.

 

이 REST API, 이게 뭔지 스스로 정리할 겸 기록을 남겨보고자 합니다.

REST란?

Representational State Transfer.

REST는 자원을 URI로 식별하고, HTTP Method를 활용해 자원의 상태를 전송하는 스타일입니다.

 

더 확실하게 말하면,

자원을 URI를 통해 명시하고, HTTP Method를 통해 적용하는 것을 의미합니다.

 

- HTTP Method?

1. POST, GET, DELETE 등, 어디선가 들어 본 메소드들이 HTTP Method로 불립니다.
2. REST에서는 "CRUD" 를 구현할 때 사용됩니다.

- CRUD?

1. (C)reate : 생성을 담당하며, "POST" Method가 담당합니다.
2. (R)ead : 읽기를 담당하며, "GET"
3. (U)pdate : 수정을 담당하며, "PUT", "PATCH"
4. (D)elete : 삭제를 담당하며, "DELETE"
Q. 어? 수정은 왜 PUT과 PATCH 두개로 표현해요?
수정 범위에 따라 구분하고 있습니다.
"PATCH" Method는 객체의 "일부"를 수정할 때,
"PUT" Method는 객체 "전체"를 수정할 때 사용됩니다.

우리가 게임을 하다 보면, 서버 "패치"한다고들 하죠,
일부 버그들을 수정할 때. 그렇게 이해하면 쉽습니다.

 

REST의 장단점?

장점

  1. HTTP 프로토콜을 그대로 사용합니다. 그 말은, "REST"를 구현하기 위해 새로운 인프라를 만들 필요가 없어요.
  2. 서버, 그리고 클라이언트간 역할을 명확히 분리할 수 있습니다.
  3. "HTTP" 프로토콜을 사용할 수 있는 모든 플랫폼에서 사용할 수 있습니다.
  4. 보다 명확하고 직관적으로 Method를 구성하기 때문에, 협업과 프로세스 의도를 이해하기가 쉽습니다.

단점

  1. Over-fetching/Under-fetching 문제가 있습니다.
    클라이언트가 필요 이상으로 데이터를 받거나, 필요한 데이터를 받지 못하는 경우가 발생할 수 있어요.
    이를 해결하기 위해, GraphQL이란 기술이 탄생했답니다. 이건 나중에 알아보죠.
  2. HTTP에 의존적입니다.
    장점이었던 HTTP 프로토콜에 대한 의존성은, 역으로 다른 프로토콜을 활용하는 데 제약이 있을 수 있습니다.

REST API란.

Representational State Transfer Application Programming Interface.

앞서 설명한 REST를 기반으로 작성 된 API를 말합니다.

 

REST API의 규칙

1. API의 URI는 명사를 사용하여야 한다.

  • 잘못된 예 : http://xxx.com/read-now
  • 옳은 예 : http://xxx.com/book

2. 대문자가 아닌, 소문자를 사용하여야 한다.

  • 잘못된 예 :  http://xxx.com/READ
  • 옳은 예 :  http://xxx.com/read

3. 언더바(_) 가 아닌, 하이픈(-)을 사용한다.

  • 잘못된 예 : http://xxx.com/read_book
  • 옳은 예 :  http://xxx.com/read-book

4. Method를 URI에 포함하지 않는다

  • 잘못된 예 : http://xxx.com/get-book/1
  • 옳은 예 :  http://xxx.com/book/1

RESTful API란

REST를 기반으로 작성 된 API를 말합니다.

네, REST API와 같은 설명이지만 다르게 말하고 있어요.

  • "REST"를 기반으로 작성한 모든 API는 "REST API"라 말할 수 있다.
  • 하지만, "REST"를 사용하지만 올바르지 않게 사용한 경우는 "RESTful API"라 말할 수 없다.
  • 즉, 완벽한 REST API는 RESTful API라고도 말할 수 있다.

예시

1. 기존에 있던 데이터를 수정하는 API

 -> http://xxx.com/book/1 (POST)

 -> http://xxx.com/book/1 (PUT)

이 경우, "수정"은 "POST"가 아닌, "PUT" 또는 "PATCH"로 진행하여야 합니다.

"POST"를 사용한 것은 "REST API"이지만,

"PUT"을 사용한 것은 "RESTful API"이자 "REST API"인 것이죠.

 

2. 기존 책 정보를 읽어오는 API

 -> http://xxx.com/get_BOOK/1 (GET)

 -> http://xxx.com/book/1 (GET)

이 경우, Method는 맞지만 REST API의 규칙을 어기고 있습니다. 이 경우는 "REST API"로 불립니다.

그 아래 URL의 경우엔 "RESTful API"이자 "REST API"인 것이죠.

쉽게 말하면...

REST의 규칙을 따르되, 보다 엄격한 규칙을 반영하고 있는 API를 "RESTful API"라 합니다.

그 외 "REST"의 규칙을 따르는 모든 API는 REST API라 부르면 됩니다.

마치며

많은 기업에서 "RESTful API 구현 가능" 또는 "REST 구현 가능"을 명시하고 있습니다.

우리 모두 구현을 할 수는 있으니, 이론에 대해서 빠삭하게 알고 있다면

기술면접에서 정말 좋은 효과가 있지 않을까요?

 

이 과정에서 얻은 교훈은 간단합니다.

"REST API" 구현에 있어 필요한 "규칙"을 좀더 확실하게 알 수 있었다는 겁니다.

당장 회사에 구현 해 둔 API들 한번 싹 점검 해야겠네요.