159. Level 1 - 리소스별 고유 URI 할당

핵심 인사이트: 리처드슨 성숙도 모델의 첫 번째 진화(Level 1)는 '모든 것을 뭉뚱그리던 단일 창구(Level 0)'에서 벗어나, 각각의 데이터(자원)마다 고유한 이름표(URI)를 달아주는 것이다. 비로소 자원(Resource)이라는 개념이 눈을 뜨기 시작한 단계다.

Ⅰ. 성숙도 모델 Level 1의 개념

Level 1 (Resources) 단계는 REST 아키텍처를 향한 첫걸음으로, API가 다루는 모든 데이터와 객체를 개별적인 자원(Resource) 으로 분리하고, 각각의 자원마다 고유한 주소인 URI(Uniform Resource Identifier) 를 할당하는 아키텍처 스타일입니다.

Ⅱ. Level 0과의 비교를 통한 이해

Level 0에서는 시스템의 단일 엔드포인트(예: /api)로 모든 요청을 보냈지만, Level 1에서는 다루고자 하는 대상(명사)에 따라 주소가 명확하게 갈라집니다.

[ Level 0: 단일 엔드포인트 방식 ]
POST /hospitalService
{ "action": "getUser", "userId": 123 }
POST /hospitalService
{ "action": "getDoctor", "doctorId": 456 }

[ Level 1: 자원별 고유 URI 할당 방식 ]
POST /users/123       (123번 환자 자원 식별)
POST /doctors/456     (456번 의사 자원 식별)

Ⅲ. Level 1 아키텍처의 한계점

Level 1은 자원을 명사형 URI로 멋지게 분리해 냈지만, 아직 행위(Verb)의 분리를 이루지 못한 반쪽짜리 REST입니다.

  1. HTTP 메서드의 오용 (보통 POST로 통일)
    • 자원을 지칭하는 주소는 나뉘었지만, 여전히 조회를 하든(GET), 데이터를 지우든(DELETE) 상관없이 모든 요청을 POST 메서드 하나로 덮어쓰는 오류를 범합니다.
  2. 명확하지 않은 상태 코드
    • 여전히 작업의 성공/실패 여부를 판단할 때 HTTP 상태 코드(예: 201 Created, 404 Not Found)를 활용하지 않고, 응답 바디의 JSON 메시지({ "result": "fail" })에 의존하는 경향이 큽니다.

Ⅳ. Level 1의 실무적 의의

비록 완벽한 REST는 아니지만, 자원을 식별할 수 있는 고유 URI 체계(/users, /orders/99)를 갖췄다는 것만으로도 시스템의 계층 구조를 직관적으로 이해할 수 있게 되며, 향후 완벽한 RESTful(Level 2 이상)로 나아가기 위한 강력한 뼈대가 됩니다.

📢 섹션 요약 비유: 구청에 '통합 민원함' 딱 1개만 있던 시절(Level 0)을 지나, 드디어 '여권 창구', '주민등록 창구', '세무 창구'라는 고유한 부서(URI)로 쪼개진 상태입니다. 하지만 창구만 나뉘었을 뿐, 접수나 발급이나 취소(HTTP Method)를 모두 한 장의 통일된 종이(POST)로만 처리하고 있어 아직 조금 답답한 행정 시스템입니다.