RESTful API란?
RESTful API는 REST 원칙을 따르는 API입니다. REST(Representational State Transfer)는 인터넷 상의 시스템 간 상호작용을 위한 아키텍처 스타일입니다. RESTful API는 자원(Resource)의 표현(Representation)을 통해 상태 정보(State)를 주고 받는 구조로, 웹의 기본 프로토콜인 HTTP를 이용하여 구현됩니다.
💡RESTful API의 핵심 구성 요소
자원(Resource): REST 아키텍처에서 모든 것은 자원으로 표현됩니다. 자원은 서버에 저장된 데이터나 서비스 같은 웹의 구성 요소를 의미하며, 고유한 URI(Uniform Resource Identifier)를 통해 접근할 수 있습니다.
표현(Representation): 클라이언트가 서버로부터 자원의 상태(정보)를 요청할 때, 서버는 해당 자원의 상태를 JSON, XML 등의 형태로 전달합니다.
상태 전달(State Transfer): 클라이언트의 요청에 따라 서버의 자원 상태가 전달되며, 이는 표현을 통해 이루어집니다. 클라이언트는 이러한 상태 정보를 바탕으로 작업을 수행합니다.
RESTful API의 설계 원칙
- 클라이언트-서버 구조(Client-Server): 클라이언트와 서버는 서로 독립적으로 분리되어 있으며, 각각의 역할이 명확히 구분됩니다.
- 무상태성(Stateless): 각 요청은 독립적이며, 서버는 클라이언트의 상태를 유지하지 않습니다. 모든 요청은 필요한 모든 정보를 포함해야 합니다.
- 캐시 가능(Cacheable): RESTful API 응답은 캐시 가능해야 하며, 이는 네트워크 효율성을 높이고 클라이언트의 요청에 빠르게 응답할 수 있게 합니다.
- 계층화된 시스템(Layered System): 클라이언트는 요청을 보내는 서버와만 직접 통신합니다. 요청 처리 과정에서 여러 다른 서버(계층)를 거치게 될 수 있지만, 클라이언트는 중간 과정이나, 내부 동작을 알 필요가 없습니다.
RESTful API 요청의 구성
RESTful API의 요청은 아래와 같은 구성 요소들로 이루어집니다.
고유 리소스 식별자(Uniform Resource Identifier, URI)
자원을 식별하는데 사용하는 고유한 식별자로, 요청 엔드포인트라고도 부릅니다. 서버에 요청할 자원을 명확하게 지정하기 위해 사용합니다.
HTTP 메서드
HTTP 메서드는 클라이언트가 리소스에 수행하려는 행위(Action)를 서버에 전달하는 방법입니다.
- GET: 자원을 조회하거나 검색 (데이터를 변경하지 않음)
- POST: 새로운 자원을 생성
- PUT: 기존의 자원을 완전히 대체
- PATCH: 리소스의 일부분만 수정
- DELETE: 자원을 삭제
HTTP 헤더
HTTP 헤더는 요청·응답 간에 메타 데이터(컨텐츠 유형, 인증 정보 등)을 제공합니다.
e.g. Content-Type: 응답 본문의 타입에 대한 정보 / Authorization: 사용자 인증 정보 등
예시
- 회원가입
- POST /registerUser - URI에 행위를 나타내는 단어(register)를 사용하고 있습니다. RESTful한 API는 HTTP 메서드를 통해 행위를 표현하고, URI는 리소스 표현에 집중해야 합니다. RESTful하게 수정한 예시 → POST /users
RESTful API의 장점과 한계
장점
- HTTP 프로토콜의 사용: HTTP 프로토콜을 기반으로 하므로, 별도의 인프라 구축 없이 기존 웹 인프라를 그대로 활용할 수 있습니다.
- 플랫폼 독립적: HTTP를 사용하기 때문에, 다양한 플랫폼(e.g. 윈도우, 리눅스, 안드로이드 등)에서 호환되어 구현과 사용이 가능합니다.
- 명확한 의도: HTTP 메서드와 상태 코드(200 OK, 404 Not Found 등)를 사용하여 API의 의도와 상태를 명확하게 표현할 수 있습니다.
- 클라이언트-서버 구조의 분리: RESTful API는 클라이언트와 서버 간의 역할을 명확하게 분리합니다. 이는 애플리케이션의 확장성과 유지보수성을 향상시킬 수 있습니다.
한계
- HTTP 메소드의 제한: HTTP 메소드는 그 수가 제한적이어서, 복잡한 연산이나 특정한 행위를 표현하는 데 한계가 있을 수 있습니다.
- 헤더 테스트 어려움: 특정 HTTP 헤더(e.g. Authorization)는 브라우저에서 직접 테스트하기가 어려울 수 있습니다. 이는 개발 과정에서 추가적인 테스트 도구나 방법을 요구할 수 있습니다.
- 표준의 부재: REST는 아키텍처 스타일 가이드라인을 제공하지만, 엄격한 표준이 존재하지 않습니다. 이로 인해 API 설계자에 따라 해석이나 구현 방식이 다를 수 있으며, 일관성 유지가 어려울 수 있습니다.