4.RESTful API 요약

REST(Representational State Transfer)는 Roy Fielding이 제안한 아키텍처 스타일로, HTTP라는 웹 기술을 기반으로 리소스를 자원으로 보고, 이를 일관된 방식(Uniform Interface)으로 처리함으로써 확장성, 단순성, 분산 환경에 강한 시스템 설계를 지향함

요소	의미
리소스 식별(URI)	명사 중심의 리소스 식별자
HTTP 메서드(Verbs)	리소스에 대한 동작 (GET / POST / PUT / DELETE 등)
표현(Representation)	JSON, XML 등의 리소스 표현 방식
상태 전이(State transfer)	HATEOAS로 표현됨
무상태성(Stateless)	요청마다 필요한 정보 포함
계층 구조(Layered system)	게이트웨이, 캐시 등 중간 계층 허용

1. REST의 성숙도 모델

하지만 현존하는 실제 시스템들은 유지비용 때문에 로이 필딩이 주장하는 REST 아키텍처를 모두 지키기 어려운 경우가 많음

Leonard Richardson은 REST의 성숙도 모델(Richardson Maturity Model, RMM) 을 제안함

이론상으로는 Level3까지 충족되어야 진정한 의미의 RESTful API라고 볼 수 있음

1-1. Level 0 – The Swamp of POX (Plain Old XML)

URI는 하나 (/api), 모든 동작은 POST, 메시지 본문만 바뀜
RPC 스타일과 비슷

단점
URI와 HTTP 메서드를 전혀 활용하지 않음, URI로 리소스를 식별하기 어려움

JSON 응답 값


POST /api
 
{
  "method": "getUser",
  "params": { "id": 1 }
}

1-2. Level 1 - 리소스 중심(Resource-Oriented)

각 리소스를 개별 URI로 식별함 (예: /users/1)
여전히 모든 동작은 POST로 처리
단점 - HTTP 메서드의 의미 (GET, PUT, DELETE)를 제대로 활용하지 않음

HTTP


POST /users/1/delete

1-3. Level 2 - HTTP 메서드 활용(Method-Oriented)

리소스를 URI로 식별하고, HTTP 메서드(GET, POST, PUT, DELETE 등)에 따라 동작을 구분
Restful API에 가까운 형태
대부분의 현대 웹 API는 이 레벨을 유지하고 있음
JSON 응답 데이터만 가지고는 의미를 파악하기가 어려울 수 있음(필드의 수가 많을 경우)

HTTP


GET /users/1          // 사용자 조회
PUT /users/1          // 사용자 수정
DELETE /users/1       // 사용자 삭제
POST /users           // 사용자 생성
 
{
  "id": 2025,
  "status": "SHIPPED"
}

1-4. Level 3 - HATEOAS (Hypermedia as the Engine of Application State)

서버가 클라이언트에게 응답 내에 링크를 포함해 상태 전이를 안내함
클라이언트는 하드코딩된 URI 없이도 링크를 따라 다음 행동을 결정할 수 있음

JSON 응답 값


{
  "id": 2025,
  "status": "SHIPPED",
  "_links": {
    "profile" : { "href": "/swagger-ui/index.html" } // API 참조 문서 링크
    "self": { "href": "/orders/2025" }, // 현재 요청한 API URI
    "cancel": { "href": "/orders/2025/cancel" }, // 주문 취소
    "track": { "href": "/orders/2025/track" } // 주문 상태 추적
  }
}