REST API(Representational State Transfer API)의 개요 및 상세 설명

 

1. 웹 자원의 효율적 공유를 위한 아키텍처, REST API의 개요

가. REST API의 정의

• 웹의 기존 인프라(HTTP)를 그대로 활용하기 위해 **자원(Resource), 행위(Verb), 표현(Representation)**으로 구성된 네트워크 아키텍처 스타일입니다.

• 로이 필딩(Roy Fielding)이 박사 학위 논문에서 제안하였으며, HTTP 프로토콜의 의도를 가장 잘 살린 인터페이스 설계 방식입니다.

나. REST API의 핵심 구성 요소 3가지

1. 자원 (Resource): 모든 자원은 고유한 URI(Uniform Resource Identifier)를 가집니다.

2. 행위 (Verb): 자원에 대한 조작은 HTTP Method(GET, POST, PUT, DELETE)를 통해 수행합니다.

3. 표현 (Representation): 클라이언트와 서버가 데이터를 주고받는 형태(JSON, XML 등)를 의미합니다.

---

2. REST API의 주요 설계 원칙 (Constraint)

REST API로 인정받기 위해서는 다음 6가지 가이드라인을 준수해야 합니다.

원칙	상세 설명
Client-Server	사용자 인터페이스와 데이터 저장소를 분리하여 독립적 발전을 도모함
Stateless	서버는 클라이언트의 상태를 저장하지 않음 (요청마다 필요한 모든 정보 포함)
Cacheable	HTTP의 기존 캐싱 기능을 활용하여 네트워크 효율성 향상
Uniform Interface	자원 식별, 메시지를 통한 자원 조작 등 인터페이스의 일관성 유지
Layered System	다중 계층으로 구성 가능 (보안, 로드 밸런싱 등 중간 매체 활용)
Code on Demand	(선택적) 서버에서 스크립트를 클라이언트로 보내 실행 가능하게 함

---

3. REST API의 주요 메서드 및 인터페이스 특징

가. 주요 HTTP Method 매핑 (CRUD)

• GET: 자원의 조회 (Read)

• POST: 자원의 생성 (Create)

• PUT: 자원의 전체 수정 (Update/Replace)

• PATCH: 자원의 일부 수정 (Partial Update)

• DELETE: 자원의 삭제 (Delete)

나. RESTful한 설계를 위한 URI 규칙

• 명사 사용: /getUsers (X) → /users (O) 행위는 URL에 포함하지 않음

• 계층 구조: 슬래시(/)는 계층 관계를 나타내는 데 사용

• 소문자 권장: 가독성을 위해 하이픈(-)은 사용하되, 밑줄(_)이나 대문자는 지양함

---

4. REST API의 장단점 

가. 장점 및 단점

• 장점:

  • 범용성: HTTP 표준을 따르므로 플랫폼에 독립적임.

  • 가독성: API의 목적이 URI와 Method만으로 명확히 드러남.

  • 확장성: 서버와 클라이언트의 분리로 각각 독립적인 확장이 용이함.

• 단점:

  • 표준의 부재: 엄격한 가이드라인은 있지만 공식 표준이 없어 'Self-descriptive' 달성이 어려움.

  • Overfetching/Underfetching: 필요 이상의 데이터를 받거나, 정보 부족으로 여러 번 요청해야 함.