REST와 HTTP의 차이 (feat. RESTful API)
Introduction
REST와 HTTP는 웹 통신에서 매우 밀접하게 관련되어 있지만, 서로 다른 개념을 가집니다.
AWS API Gateway를 생성할때도 REST와 HTTP가 따로 분리되어 있기에 "서로 동등한 관계고 둘 중 선택해서 쓰는게 아닐까(?)"하는 생각이 들기도 하지만 이 둘은 사실 명확히 다른 개념입니다.
비유적으로 먼저 설명하자면, HTTP는 "도로"이고, REST는 그 도로를 "어떻게 효율적으로 사용할지에 대한 운전 규칙"이라고 할 수 있습니다.
1. HTTP (HyperText Transfer Protocol)
정의
HTTP는 인터넷에서 데이터를 주고받기 위한 통신 프로토콜(규칙)입니다. 클라이언트(웹 브라우저, 앱 등)와 서버(웹 서버) 사이에 HTML 문서, 이미지, JSON 데이터 등 다양한 정보를 전송하기 위한 "규칙"을 정의합니다.
역할
HTTP는 요청/응답 모델로 클라이언트가 요청(Request)을 보내면 서버가 응답(Response)을 돌려주는 방식으로 작동합니다.
-
메서드:
GET,POST,PUT,DELETE등과 같은 HTTP 메서드를 사용하여 클라이언트가 서버에 어떤 종류의 작업을 원하는지(데이터 가져오기, 생성, 수정, 삭제 등)를 나타냅니다. -
상태 코드:
200 OK,404 Not Found,500 Internal Server Error등과 같은 상태 코드를 통해 요청의 성공 여부나 문제 발생 여부를 클라이언트에게 알려줍니다. -
무상태성(Stateless): 각 HTTP 요청은 독립적이며, 서버는 이전 요청의 상태를 기억하지 않습니다. (물론 세션이나 쿠키 등을 통해 상태를 관리하기도 하지만, 프로토콜 자체는 무상태성을 지향합니다.)
-
위치: 네트워크 계층 모델에서 애플리케이션 계층에 속합니다. 즉, 실제 데이터 전송 방식(TCP(4계층)/IP(3계층)) 위에 구축된 상위 레벨의 통신 규약입니다.
2. REST (Representational State Transfer)
정의
REST는 HTTP 프로토콜을 기반으로한 웹 서비스를 설계하는 데 사용되는 소프트웨어 아키텍처 스타일(설계 원칙)입니다.
즉, 웹의 장점(확장성, 유연성 등)을 최대한 살리기 위해 만들어진 일련의 HTTP 제약 조건 및 원칙입니다.
해당 주요 원칙을 살펴 보도록 합시다.
주요 원칙
-
자원(Resource): 통신 내 주고 받는 모든 것을 "자원"으로 간주하고, 각 자원에 고유한 URI를 부여하여 식별합니다.
(예:/users,/products/123) -
표현(Representation): 자원은 JSON, XML, HTML 등 다양한 형태로 표현될 수 있습니다. 클라이언트는 원하는 자원을 특정 형태(DTO)로 요청하고 서버는 해당 형태로 응답합니다.
-
자원에 대한 행위를 HTTP 메서드로 표현: 자원에 대한 CRUD(Create, Read, Update, Delete) 작업에 대해 URI 내에 동사(예:
getUser,deleteProduct)를 사용하지 않습니다.
한 자원에 대해 명사(/users)를 사용하며, HTTP 메서드(POST,GET,PUT,DELETE)를 통해 서로 다른 동작을 표현합니다.- GET /users (모든 사용자 조회)
- POST /users (새 사용자 생성)
- PUT /users/123 (ID가 123인 사용자 수정)
- DELETE /users/123 (ID가 123인 사용자 삭제)
이처럼 REST 스타일 원칙을 잘 따르는 API를 우리는 "RESTful API"라고 부릅니다.
⚠️ 만약 REST 설계 원칙을 지키지 않고, 마음대로 API를 짜게된다면 (예를 들어 API에
/getUsers와 같이 동사를 넣는다거나, 모든 CRUD 작업을POST로 퉁쳐 버리거나)
이는 RESTful API가 아닌 단순한 HTTP API라고 할 수 있습니다.
같은 URI(/users)을 사용했을때의 문제점은?
이처럼 REST 방식으로 사용하면
GET /users와POST /users처럼 결국 같은 URI(명사)을 사용하게 되는데 헷갈리지 않을까요?
결론부터 말하자면, 헷갈리지 않습니다.
그 이유는 HTTP 메서드(GET, POST, PUT, DELETE 등)가 "어떤 종류의 작업을 수행할지"를 명확하게 지시하는 동사의 역할을 대신 해주기 때문입니다.
URL(users)은 "대상 자원(Resource)"을 나타내는 명사이고, HTTP 메서드는 그 자원에 대해 "수행할 행위(Action)"를 나타내는 동사라고 생각하시면 됩니다.
예시
GET과 POST의 예시를 다시 살펴보겠습니다
-
GET /users- 메서드:
GET(가져오기) - 자원:
/users(사용자들) - 의미: "사용자들"이라는 자원을 가져와라(조회하라)는 명령입니다. 서버는 이 요청을 받으면 모든 사용자 목록을 응답으로 돌려줍니다.
- 메서드:
-
POST /users- 메서드:
POST(새로 생성하기) - 자원:
/users(사용자들) - 의미: "사용자들"이라는 자원 컬렉션에 새로운 사용자 자원을 생성해라는 명령입니다. 이 요청에는 일반적으로 생성할 사용자의 정보가 요청 본문(body)에 담겨 전달됩니다.
- 메서드:
이처럼 URL은 자원을 식별하고, HTTP 메서드는 그 자원에 대해 어떤 작업을 할 것인지를 명별하게 구분해 줍니다.
왜 이렇게 설계되었을까요? (RESTful 원칙)
이는 REST 아키텍처 스타일의 중요한 원칙 중 하나인 명사인 URI과 동사인 HTTP 메서드의 분리 때문입니다.
-
URI는 자원을 식별한다 (명사)
GET /getUsers(X) →GET /users(O)DELETE /deleteProduct/123(X) →DELETE /products/123(O)- 즉, URI 자체에 어떤 동작을 할 것인지 동사를 넣지 않습니다. URI는 오직 어떤 "자원"인지만을 나타냅니다.
-
HTTP 메서드가 행위를 정의한다 (동사)
- 자원에 대한 CRUD(Create, Read, Update, Delete) 작업을 HTTP 표준 메서드에 매핑합니다.
GET: 자원 조회POST: 자원 생성PUT: 자원 전체 수정 또는 생성PATCH: 자원 부분 수정DELETE: 자원 삭제
- 자원에 대한 CRUD(Create, Read, Update, Delete) 작업을 HTTP 표준 메서드에 매핑합니다.
정리
| 특징 | HTTP | REST |
|---|---|---|
| 개념 | 데이터를 주고받는 통신 프로토콜 (규약) | 웹 서비스를 설계하는 아키텍처 스타일 (설계 원칙) |
| 범위 | 웹 통신의 기본적인 규칙 | HTTP 프로토콜을 포함하여 웹의 장점을 활용하는 API 설계 원칙 |
| 관계 | HTTP는 REST를 구현하기 위한 주요 프로토콜이다. | REST는 HTTP를 기반으로 만들어진다. |
| 비유 | 데이터가 오가는 도로 | 도로를 효율적으로 사용하는 운전 규칙 |
결론적으로, HTTP는 웹에서 데이터를 전송하는 "수단"이고,
REST는 그 수단인 HTTP를 "어떻게 효과적으로 사용하여 웹 서비스를 만들 것인가"에 대한 "철학이자 가이드라인"입니다.
🤔 RESTful API는 HTTP 프로토콜만 가능한가요?
대부분의 RESTful API는HTTP프로토콜을 사용하지만, 이론적으로는HTTP외의 다른 프로토콜 위에서도 REST 원칙을 적용할 수 있습니다. 하지만 실제로는 HTTP가 가장 보편적으로 사용됩니다.
또한 RESTful API를 구성하였을 때, GET /users와 POST /users는 같은 "user" 자원에 대한 요청이지만, HTTP 메서드가 다르기 때문에 서버는 이를 전혀 다른 두 가지 행위(조회/GET과 생성/POST)로 정확하게 구분하고 처리하게 됩니다.
