[Web] REST API란?

Web

[Web] REST API란?

s_ih_yun 2025. 6. 4. 01:05

728x90

1. REST

💡 REpresentational State Transfer

등장 배경 : 복잡한 네트워크 통신(ex. 인터넷)과 멀티 플랫폼(ex. 다양한 브라우저와 모바일 디바이스 등)의 등장에 따라 이를 관리하기 위한 지침으로 만들어졌다

1.1. REST 란?

소프트웨어 프로그램 아키텍처의 한 형식
- HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)를 명시하고
- HTTP Method (POST, GET, PUT, DELETE, PATCH 등)을 통해
- 해당 자원(URI)에 대한 CRUD Operation을 적용하는 것을 의미
  - Create : 데이터 생성 (POST)
  - Read : 데이터 조회 (GET)
  - Update : 데이터 수정 (PUT, PATCH)
  - Delete : 데이터 삭제 (DELETE)자원을 이름으로 구분하여 해당 자원의 상태를 주고 받는 모든 것

1.2. 구성요소

자원(Resource) : HTTP URI
- Client는 URI를 이용해 자원을 지정 해당 자원의 상태(정보=Payload)의 조작을 Server에 요청
자원에 대한 행위(Verb) : HTTP Method
자원에 대한 행위의 표현(Representation of Resource)
- JSON, XML, TEXT, RSS등 여러 형태의 응답

1.3. 특징 및 장단점

특징
1. Uniform (유니폼 인터페이스)
  - 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일
2. Stateless (무상태성)
  - 작업을 위한 상태 정보를 따로 저장 / 관리하지 않는다
3. Cacheable (캐시 가능)
  - HTTP라는 기존 웹 표준을 그대로 사용
  - → HTTP의 캐싱 기능 적용 가능 (Last-Modified 태그, E-Tag를 이용하여 구현 가능)
4. Self-descriptiveness (자체 표현 구조)
  - REST API 메시지만 보고도 쉽게 이해 가능
5. Client-Server 구조
  - Client, Server에서 개발할 내용이 명확하고 의존성 감소
    - 각각 Client는 사용자 인증이나 컨텍스트(세션, 로그인 정보), Server는 API 제공 등을 직접 관리하는 구조
6. 계층형 구조
  - 다중 계층 구성 가능→ PROXY, 게이트웨이 같은 네트워크 기반 중간 매체 사용 가능
  - → 보안, 로드 밸런싱, 암호화 계층 추가하는 구조상 유연성
장단점

장점

- HTTP 프로토콜 인프라를 그대로 사용하여, REST API를 위한 별도 인프라 구축 필요 X
- HTTP 프로토콜 표준을 최대한 활용하여, 여러 추가적인 장점 함께 가져감
- HTTP 표준 프로토콜을 따르는 모든 플랫폼에서 사용 가능
- Hypermedia API의 기준을 충실히 지키며 범용성 보장
- REST API 메시지가 의도하는 바를 명확히 나타냄 → 의도하는 바 쉽게 파악 가능
- 여러가지 서비스 디자인에서 생길 수 있는 문제 최소화 - 서버와 클라이언트 역할을 명확히 분리

단점

- 표준이 존재하지 않음
- 사용 가능한 메소드가 4가지 뿐임 (HTTP Method 형태가 제한적)
- 브라우저를 통해 테스트할 일이 많은 서비스라면, 쉽게 고칠수 있는 URL보다 Header 정보의 값을 처리해야 하므로 전문성이 요구됨
- 구형 브라우저가 제대로 지원해주지 못하는 부분 존재 (ex. PUT / DELETE 사용 불가, pushState 지원 안함)

2. REST API

💡REST의 원리를 따르는 API

2.0. API 란?

💡Application Programming Interface

소프트웨어 응용 프로그램에서 다른 소프트웨어 구성 요소 또는 서비스와 상호 작용하기 위한 인터페이스를 제공하는 프로그래밍 기술

2.1. REST API 설계 규칙

2.1.1. 중심 규칙

URI는 정보의 자원을 표현해야 한다
자원에 대한 행위는 HTTP Method (GET, POST, PUT, DELETE 등)으로 표현한다
- 행위는 URI에 포함하지 않는다

2.1.2. 세부 규칙

URI는 전달하고자 하는 자원의 명사를 사용한다
- 컨트롤 자원을 의미하는 경우 예외적으로 동사 허용
URI 경로에는 소문자가 적합하다
파일 확장자는 URI에 포함하지 않는다
- 대신 Accept Header를 사용 (ex. GET : http://syun.com/orders/2/Accept: image/jpg )
슬래시 구분자(/)는 계층 관계를 나타내는데 사용한다
URI 마지막 문자로 슬래시(/)를 포함하지 않는다
밑줄(_)은 URI에 사용하지 않고, 하이픈(-)을 사용한다
리소스 간에 연관 관계가 있는 경우(ex. GET : /users/{userid}/devices (일반적으로 소유(has)의 관계를 표현할 때) )
→ /리소스명/리소스 ID/관계가 있는 다른 리소스명

3. RESTful API

💡REST API의 설계 규칙을 올바르게 지킨 시스템
- REST를 REST답게 쓰기 위한 방법으로, 누군가 공식적 발표한 것은 아니다

REST API의 구성 요소를 따르면서, URI와 HTTP 메소드를 적절하게 사용하여 자원 조작
- REST API를 개선하고, 보다 일관성 있는 API 구현하도록 해준다
- 요청을 보내는 주소만으로도 어떤 것을 요청하는지 파악 가능 (더 간편하고 직관적인 구조)
성능이 중요한 상황이라면 굳이 RESTful한 API를 구현할 필요 X
목적 : 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것