Please enable JavaScript.
Coggle requires JavaScript to display documents.
REST 아키텍처 - Coggle Diagram
REST 아키텍처
REST(Representational State Transfer)
웹 서비스를 위한 아키텍처 스타일 중 하나로, HTTP 프로토콜을 기반으로 클라이언트와 서버 간의 통신을 위한 규칙과 규약 제공
핵심 철학
프로토콜이 아니라 "설계 원칙(Architecture Style)"
REST의 중심: 무엇(자원)을, 어떤 행위로, 어떤 형태로 보낼 것인가
"RESTful하게 설계했다"는 건 특정한 기술이 아니라 철학을 잘 지켰다는 뜻
Resource(자원): 서버에 존재하는 데이터/엔티티. URI로 식별
Verb(행위): 자원을 조작하는 방식, 즉 HTTP Method
- 예: GET, POST, PUT, PATCH, DELETE
Representation(표현): 리소스의 상태를 전송하는 방식
6가지 제약 조건
Client-Server 구조
클라이언트는 UI와 요청만 담당하고, 서버는 데이터와 로직을 담당.
서로 독립적으로 개발 및 배포 가능.
무상태성 (Stateless)
서버는 클라이언트의 상태(세션)을 보존하지 않으며, 요청마다 필요한 모든 정보를 포함해야 함.
스케일링이 쉬워지고, 장애 복구도 간단해짐.
캐시 가능 (Cacheable)
HTTP의 캐시 매커니즘을 적극 활용할 수 있음.
ETag, Cache-Control, Last-Modified 등을 통해 응답 재사용 가능.
일관된 인터페이스 (Uniform Interface)
REST의 핵심으로, URI는 리소스만 나타내야 하고, HTTP Method로 동작을 구분.
요청/응답의 구조가 일관되어야 함.
예: GET /users/1 -> 항상 user 리소스 하나 반환
1. 자원의 식별 (Unique Resource Idetification)
URI는 "명사형 리소스"를 나타내야 한다
예) /users/1, /orders/22/items
-
3. 자기서술적 메시지 (Self-descriptive Message)
요청과 응답만 봐도 구조를 유추할 수 있어야 함
(Content-Type, Status Code, Link, ETag 등)
4.HATEOAS (Hypermedia As TheEngine Of Application State)
REST API의 응답 안에 "다음에 가능한 행동(다른 리소스로 이동하는 링크)"을 포함해, 클라이언트가 별도 문서 없이도 응답만 보고 상태 전이를 할 수 있게 만드는 것.
Fielding이 정의한 REST의 핵심 제약이지만, 응답이 비대해지고 구현 복잡도가 높아 실무에서는 거의 사용되지 않음.
계층화 (Layered System)
API 서버는 여러 중간 계층(예: 인증 프록시, 로드밸런서)을 둘 수 있음.
각 계층은 서로의 내부 구조를 모른 채 요청을 전달함.
Code on Demand (선택적)
서버가 클라이언트로 실행 가능한 코드를 전달할 수 도 있음. (예:JS 스크립트)
거의 사용되진 않지만, REST 이론상 제약에 포함.
REST API vs. RESTful
RESTful
REST의 6가지 제약을 충실히 준수한 정도를 강조하는 표현.
문서마다 혼용되지만, 보통 제약 충족 여부를 구분점으로 본다.
<예시>
- URI가 명사형이고, 리소스 중심적으로 잘 표현됨
- 서버가 상태를 저자하지 않음
- HTTP 상태코드를 일관성 있게 사용
- 요청/응답의 구조가 예측 가능
-
탄생 배경
HTTP 사양 공동 설계자인 Roy Fielding이 박사논문에서 REST 아키텍처 스타일 제시.
웹이 성공한 이유를 분석하면서, 복잡하지 않고, 단순한 규칙에 따라 확장 가능한 통신 방식을 정의하려 함.
이전의 SOAP, XML-RPC 같은 복잡한 프로토콜의 문제점
- XML 포맷이 무거움
- 요청/응답 구조가 복잡
- 단순 CRUD 작업에도 불필요한 오버헤드가 많음
웹의 기본 철학(HTTP, URI, Stateless 등)을 그대로 이용해서 효율적이고 예측 가능한 아키텍처를 만드는 것이 핵심
특징
- 리소스 지향 + URI 설계로 구조가 직관적
- 무상태성으로 수평 확장과 장애 복구 유리
- HTTP 캐시를 그대로 활용해 성능 최적화
- 플랫폼 독립성/자가 서술적 메시지로 학습/활용 용이
장점
- 단순함: 별도의 프로토콜 필요 없이 HTTP만으로 동작
- 명확성: URI와 메서드 조합으로 구조가 직관적
- 확장성: 무상태성이므로 서버 확장 용이
- 호환성: 웹 표준 기반이라 브라우저/모바일/IoT 모두 사용 가능
- 캐시 활용 가능: 응답을 캐시로 재사용해 성능 향상
단점
- 복잡한 트랜잭션 처리 한계: 여러 리소스에 걸친 연산을 원자적으로 처리하기 힘듦
- 오버페칭/언더페칭 문제: 정해진 응답 구조로 안해 필요한 데이터만 선택적으로 받기 어려움
- 실시간성 부족: 요청-응답 구조라서 실시간 알림/채팅에 부적합
- 표준 강제력 부족: REST 이름만 쓰고 규칙 안 지키는 경우 많음
- 버전 관리 어려움: /v1, /v2 등 URI 버전 분리로 관리하기 복잡함
HTTP Method 성질
-
멱등성 (Idempotency)
- 멱등 메서드: GET, PUT, DELETE
- 비멱등 메서드: POST (여러 번 호출 시 매번 새로운 리소스 생성 가능)