💡 개요
오늘은 서버 개발에 사용되는 아키텍처인 REST(Representational State Transfer)에 대해 정리해 보자.
🛠️ REST
REST란 Representational State Transfer의 약자로 자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 것을 의미한다.
이를 풀어서 설명하면 다음과 같다.
- HTTP URI을 통해 어떤 자원인지 명시
- HTTP Method을 통해 해당 자원에 대한 CRUD작업이 무엇인지 명시
- HTTP Body를 통해 자원의 구체적인 정보 명시
위 세 가지가 REST의 구성 요소이기도 하다.
- 자원을 나타내는 HTTP URI
- 행위를 나타내는 HTTP Method
- 표현을 나타내는 HTTP Body
👍 REST 장점
- REST는 HTTP 프로토콜을 기반으로 하기 때문에, HTTP의 장점인 무상태(stateless) 특성을 그대로 활용할 수 있어 서버의 확장성이 뛰어나다.
- 웹뿐만 아니라 모바일 등 다양한 환경에서도 범용적으로 사용할 수 있어 호환성이 우수하다.
- 어떤 URI인지, 요청 데이터는 무엇인지만 알면 됨
👎 REST 단점
- REST는 아키텍처 스타일일 뿐 명확한 표준이 없기 때문에, 각 서비스나 개발자에 따라 설계 방식이 달라질 수 있다.
- 명확한 버전 관리 방식이 없어 API 변경 시 혼란이 생길 수 있다.
- 현업에선 URI에 버전을 포함시키는 방식을 주로 사용함
- REST는 요청-응답 방식이기 때문에 WebSocket처럼 실시간 양방향 통신이 필요한 경우에는 적합하지 않다.
- 만약 WebSocket 통신이 필요한 경우엔 따로 구현해야 함
🔥 REST 특징
- 클라이언트-서버 구조
- 클라이언트와 서버가 명확히 분리되어 독립적으로 개발 및 배포 가능
- 서버는 데이터 처리에 집중하고, 클라이언트는 사용자 인터페이스와 사용자 경험을 담당
- 클라이언트와 서버가 명확히 분리되어 독립적으로 개발 및 배포 가능
- 무상태성
- 서버는 각 요청을 독립적으로 처리하며, 이전 요청의 상태나 정보를 저장하지 않음
- 모든 요청은 필요한 정보를 모두 포함해야 함
- 캐시 처리 가능
- HTTP의 캐싱 기능을 그대로 활용 가능
- 리소스에 따라 캐시 여부를 명시하여 성능 향상과 네트워크 트래픽 절감
- 계층화된 시스템
- 클라이언트는 중간 서버(프록시, 로드밸런서 등)를 거쳐 리소스를 요청할 수 있음
- 보안, 로드 밸런싱, 캐싱 등의 기능을 계층별로 분리 가능
- 일관된 인터페이스
- REST의 핵심 원칙으로, 다양한 서비스에서도 일관된 URI, 메서드, 응답 형식을 유지
- 주요 구성 요소
- 리소스(URI)
- HTTP 메서드 (GET, POST, PUT, DELETE 등)
- 표현 (JSON, XML 등)
- 상태 코드 (200, 201, 400, 404, 500 등)
👨🏻💻 참고
'개발 일기' 카테고리의 다른 글
[개발 일기] 2025.05.02 -GraphQL, gRPC (2) | 2025.05.02 |
---|---|
[개발 일기] 2025.05.01 - ws vs wss (Feat: Nginx) (0) | 2025.05.01 |
[개발 일기] 2025.04.29 - apt-get update 하는 이유 (0) | 2025.04.29 |
[개발 일기] 2025.04.28 - HTTP 상태코드 (0) | 2025.04.28 |
[개발 일기] 2025.04.27 - Kafka + H2 포트 충돌 (0) | 2025.04.27 |