🤔 REST API랑 RESTful API, 뭐가 달라? (진짜 모름)

Intro.

굳이 내가 REST API를 따로 게시글을 쓰는 이유는 HTTP를 알고 REST를 설명하는 것이 이해하기 더 좋기 때문이다. 이게 REST와 RESTful API가 무슨 차이냐고 물어보면 설명하기 쉬운데.. REST API vs RESTful API라고 하면 참 설명을 어떻게 해야할지 막막하다.

 

---

REST의 특징

2026.02.24 - [CS] - API가 도대체 뭔데

API가 도대체 뭔데

전에 REST가 뭔지는 간단히 설명했으니 오늘은 자세하게 알아보도록 하겠다.

1. Uniform Interface (균일한 인터페이스)

URI로 지정된 자원에 대해 공통된 방식으로 소통해야 한다는 REST의 가장 중요한 원칙이다.

RESTful API의 핵심 원칙은 여기서 나온다고 생각하면 된다. 

 

2. Client - Server 구조

자원을 가지고 있는 쪽이 서버, 요청하는 쪽이 클라이언트로 명확하게 구분하여 서로의 의존성을 낮춘다. 서버는 데이터 처리에 집중하고 클라이언트는 UI와 사용자 인증 쪽에 집중하면서 서로의 개발 효율성 증대와 유지보수성을 높인다.

 

3. Chacheable (캐시가능)

REST는 기존 웹표준이었던 HTTP를 그대로 활용하기 때문에 기존 웹의 인프라를 전부 사용할 수 있다. 따라서, HTTP의 캐싱을 이용할 수 있다. 여기서 캐싱은 성능 향상을 위해 자주 사용하는 데이터를 임시 저장소(캐시)에 저장해놨다가 DB조회 없이 바로 꺼내서 사용하는 기법을 말한다. (캐싱과 캐시는 다름)

 

그럼 캐싱은 필수일까?

얼핏 들으면 캐싱이 좋아보이지만 단점도 있다. 요즘 대규모 시스템의 경우에는 DB를 조회하는 데이터 트래픽을 감당하기 힘들거나 운영비, 시스템 성능의 이유로 어느정도 필수로 여겨지는 경향이 있다. 하지만, 캐싱을 구현하면 시스템의 복잡도가 올라가고 캐싱 기법은 RAM을 사용하기 때문에 모든 경우에 좋지는 않다. 또한, 실시간으로 변하는 데이터는 캐시에 저장하는 것이 의미가 없다.

 

4. Self-descriptivness (자체 표현 구조)

REST 원칙을 따른 API의 메세지만 봐도 이게 무엇인지 무엇을 하는지 누구나 쉽게 이해할 수 있다.

 

5. Stateless (무상태성)

HTTP와 마찬가지로 이전 상태를 저장하지 않는다. 이는 단순히 들어오는 요청만 처리하면 된다는 말이다. 즉, 쉽고 빠르게 구현이 가능하고 서비스의 자유도가 높아지며 서버의 확장이 쉬워진다는 의미이다. 

 

이전 상태를 저장하고 알아서 해주는 게 더 좋은 거 아닌가?

라고 생각 할 수도 있지만, 알바를 생각하면 쉽다. 내가 다닌지 얼마 안된 식당에서 처음보는 손님이 "나 여기 자주오는 단골인데 늘 항상 주던 걸로 알아서 해줘." 라고 하면 매우 곤란할 것이다. 자신이 누구고 무엇을 원하는지 주문마다 명확하게 해야 신입인 입장에서 처리가 쉽다. 이건 서버도 마찬가지다. 이전 상황에 대한 자료나 학습 없이 바로바로 서버를 확장할 수 있다는 것이다.

 

6. 계층형 구조

클라이언트와 서버 사이에 계층을 나눠서 처리한다. 각 계층은 서로 인접한 계층끼리만 소통 가능하기에 보안 부분에서도 이점을 얻고 중간 계층에서 캐시를 가로채서 처리가 가능하게 되기 때문에 응답 시간을 단축시켜 성능 부분에서도 이점을 얻는다.

 

또 각 계층이 독립적으로 이루어져 있기 때문에 서버의 구성이 바뀐다 해도 클라이언트가 영향을 받지 않고 유연하게 서비스를 확장할 수 있게 된다.

 

---

REST API

REST API 설계의 핵심은 URI가 정보의 자원을 표현하고, 행위는 HTTP 메서드로 표현한다는 점이다.

 

URI 설계 규칙

무슨 자원인지 명확하게 적어야 하고 다음과 같은 세부 규칙들을 준수해야 한다.

• 소문자를 사용한다.
• 언더바(_) 대신 하이픈(-)을 사용한다
• 마지막에 슬래시를 포함하지 않는다
• 동사가 아닌 명사(복수형)를 사용한다.
• 계층 관계는 슬래시로 구분한다.
• 필터링이나 정렬은 쿼리 파라미터를 이용한다.

 

의도	나쁜 예 (Non-RESTful)	좋은 예 (RESTful)
유저 목록 조회	GET /get_all_users	GET /users
특정 유저 등록	POST /insert_user	POST /users
5번 유저 삭제	GET /delete_user?id=5	DELETE /users/5
3번 게시글 수정	POST /update_post/3	PATCH /posts/3

 

복수형을 사용해야 하는 이유도 여기서 나온다. 유저를 조회하는 API가 있다고 쳤을 때, 어디는 user고 어디는 users면 헷갈릴는 것도 있겠지만, GET /user로 되어 있으면, 유저를 한 명만 조회하는 건지 유저들 전체를 조회하는 건지 헷갈리기 쉽다. 반면, GET /users는 아 유저 전체를 조회하는구나라는 느낌이 바로 온다. 설령 한명을 조회하고 싶다고 해도 GET /users/1이런 식으로 쓰면 된다.

 

---

RESTful API을 지향하는 이유

RESTful API는 REST의 규칙을 엄격하게 잘 시켜서 설계한 API를 말한다. 사실 작은 규모에선 RESTful하게 만들지 않아도 문제점이 크게 안 보일 수도 있다. 하지만 서버의 규모가 커지고, 같이 일하는 개발자가 많아질수록 크나큰 수난을 겪게 될 것이다. 일단 신입 개발자가 수 많은 주소의 의미와 규칙을 통째로 다 외워야 하는 불상사가 생기게 된다.

 

사람의 문제가 아니고 서비스 측면에서도 서버의 확장과 유지보수가 힘들어지고 서버와 클라이언트가 엉켜서 서버의 작은 문제 하나가 클라이언트 죽여버릴 수도 있다.

 

이런 유혈 사태를 방지하기 위해서 개발자들은 서로 REST의 규칙을 잘 지켜서 개발하자고 약속한 것이기 때문에 사실상 반강제로 RESTful API를 개발해야 하는 것이다. (평화협정 같은 느낌)

---

REST API vs RESTful API

사실 거의 비슷한 의미로 혼용되기도 한다. 그냥 저 사람과 저 사람은 진짜 사람답다..!의 차이 정도로 보면 될 것 같다. 굳이 따지자면 REST의 규칙을 엄격하게 지키는 것이 쉽지 않기 때문에 REST의 규칙을 엄격하게 지킨 API를 RESTful API라고 하고, REST의 규칙을 어느정도 흉내만 내도 REST API라고 하는 모양새라고 생각하면 된다.