"Stateful / Stateless" 에 대해 포스팅하며 RESTful에 대한 이야기가 나왔었다.
"RESTful한 API를 설계해야한다!" 라는건 많이 듣고 사용해 왔는데, 머릿속에는 "적당히 서로 알아먹기 좋게 구현된 API 설계"라는 두루뭉술한 생각이 들어있다.
이 참에 정확히 정리해보자.
REST란 무엇인가
RESTful에 대해 알기 위해서, 우선 REST에 대해 짚어보자.
REST: 자원을 이름으로 구분하여 해당 자원의 상태(정보)를 주고 받는 모든 것
주고받는 모든 것이라... 애매모호하다. 좀 더 알아보자.
REST
- HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고,
- HTTP Method(POST, GET, PUT, DELETE, PATCH 등)를 통해
- 해당 자원(URI)에 대한 CRUD Operation을 적용하는 것을 의미한다다.
앞서 나온 문장에 적용시켜보자면, "자원(문서, 이미지 등)을 어떠한 표현(JSON, HTML 등)으로 구분하여 해당 자원의 상태를 주고받는 모든 것"이 된다.
그렇다면 REST의 특징 및 장단점을 알아보자.
REST의 특장점
- 클라이언트-서버 아키텍처(계층화): 클라이언트와 서버 간의 역할을 명확히 분리. (각각 독립적, 확장성 용이)
- 무상태성: 서버는 각 요청을 독립적으로 처리하며, 클라이언트의 상태를 유지하지 않는다. (서버의 확장성과 독립성)
- 캐시 가능: HTTP의 캐싱 메커니즘을 활용하여 응답을 캐싱 가능. (성능 향상, 네트워크 비용 절감)
- 인터페이스 일관성: 일관된 인터페이스를 제공하여, 서버에 접근하는 방식을 통일.
- 다양한 형식의 표현: 자원을 다양한 형식으로 표현할 수 있다. (JSON, XML, HTML 등)
- 자체 서술적: 메시지에 자체 설명을 포함하여 자원에 대한 정보를 전달. (클라이언트가 자원을 이해하고 적절히 처리 가능)
REST의 단점
- HTTP 프로토콜의 제한: REST는 주로 HTTP 프로토콜을 기반으로 하기 때문에, HTTP가 가지고 있는 한계와 제약을 따라야 한다. (복잡한 작업이나 비동기적인 작업 처리가 어려울 수 있음)
- 일관성 유지 및 설계의 어려움: 대규모의 시스템에서는 일관성을 유지하기 어려울 수 있다. 특히, 다양한 클라이언트와 다수의 자원이 관여하는 경우 일관성을 유지하는 것이 어려울 수 있다. (표준이 존재하지 않기 때문에 정의가 필요함)
RESTful
그럼 RESTful은 무엇인가!
REST와 RESTful
"REST"와 "RESTful"은 서로 다른 개념이 아니라, 서로 연관된 용어이다.
"REST"가 웹 서비스 아키텍처
디자인 스타일을 나타내는 것이고,
"RESTful"은 이러한 REST 아키텍처 스타일을 따르는 시스템이나 서비스를 묘사하는형용사이다.
"REST"와 "RESTful"은 같은 단어라고 해도 될 정도로 동일한 의미로 사용되고 있다.
RESTful API
RESTful까지 알아봤으니 RESTful API는 이해하기 쉬울 것이다.
API: Application Programming Interface의 약자로, 프로그램 간에 상호작용할 수 있는 인터페이스
서비스가 다른 프로그램에서 사용할 수 있도록 제공되는 메서드나 함수의 집합을 의미하며,
흔히 사용해 왔던 예시로는 HTTP POST, "/users/signup" 가 있다.
이런 API가 REST 아키텍처 스타일을 따르는 것을 RESTful API라고 한다.
이전에 API Versioning 을 하며 RESTful API에 대해 이리저리 궁리해본 경험이 있는데, 그 덕분에 REST에 대해 자세히 이해하는데 도움이 되었다.
출처
관련 포스팅
Previous Post
Following Post
