REST API는 두 컴퓨터 시스템이 인터넷을 통해 데이터를 교환하기 위해 사용하는 인터페이스다. 먼저, REST가 무엇인지 살펴보자.
REST (REpresentational State Transfer)
REST 등장 배경
Web
웹(World Wide Web, WWW)은 정보를 하이퍼텍스트로 연결하여 인터넷을 통해 공유할 수 있도록 설계된 시스템으로, 1990년대 초에 Tim Beners-Lee에 의해 등장했다. URL을 사용해 자원을 식별하고, HTTP로 자원을 전송하고, HTML을 통해 웹 페이지의 콘텐츠와 구조를 정의했다.
📖 웹의 주요 개념
- Hypertext: 텍스트 내에서 다른 문서나 리소스에 연결할 수 있는 링크를 포함하여, 사용자가 한 정보를 통해 관련된 다른 정보로 자연스럽게 이동할 수 있게 해준다.
- HTML(Hypertext Transfer Markup Language): 표현 형식으로, 웹 페이지의 구조와 콘텐츠를 정의하는 언어로, 링크, 텍스트, 이미지 등을 하이퍼텍스트 형태로 연결할 수 있게 한다.
- HTTP(Hypertext Transfer Protocol): 전송 방법으로, 웹 브라우저와 웹 서버가 정보를 주고받는 데 사용하는 프로토콜이다.
- URL(Uniform Resource Locator): 식별자로, 각 정보의 위치를 식별하는 주소로, 웹 페이지나 파일 등 모든 웹 리소스를 고유하게 식별할 수 있다.
HTTP/1.0
HTTP/1.0은 웹에서 클라이언트와 서버가 자원을 요청하고 응답하는 기본 프로토콜로 설계되었지만, 웹이 확장되며 많은 단점이 나타났다. 예를 들어, 비연결형 통신 방식은 반복적인 연결과 종료로 인해 성능 문제가 발생했다. (Cf. HTTP/1.0의 비지속 연결)
Roy Fielding은 이를 극복하면서도 웹 전체의 아키텍처를 장기적으로 유지할 수 있는 접근 방식이 필요하다고 생각했고, HTTP Object Model을 해결책으로 제시했다.
HTTP Object Model
HTTP 오브젝트 모델은 요청과 응답을 독립적인 오브젝트로 관리하며, HTTP 프로토콜에서 리소스와 메타데이터를 구조화된 형식으로 정의했다. 그리고 이 HTTP 오브젝트 모델이 4년 후 REST라는 이름으로 발표된다.
REST
REST는 'Representational State Transfer'의 약자로, 분산 하이퍼미디어 시스템(e.g. 웹)의 아키텍처 스타일이다.
Roy T. Fielding의 박사 논문 Roy T. Fielding(2000). Architectural Styles and the Design of Network-based Software Architectures 에서 구체화되었으며, REST를 통해 웹이 계속 발전하고 확장되더라도 기존 시스템과의 호환성을 잃지 않으면서도, 새로운 시스템들이 독립적이고 서로 다른 방향으로 진화할 수 있게 만들고자 했다.
REST의 제약 조건
아키텍처 스타일이란 제약조건의 집합을 의미한다. REST는 여섯 가지 제약 조건을 통해 시스템의 성능, 확장성, 신뢰성을 증대시키고, 독립적인 발전을 가능하게 한다.
1. Client-Server
클라이언트-서버 구조를 통해 관심사를 분리한다. 사용자 인터페이스와 데이터 저장을 분리해 컴포넌트 간 독립적인 발전과 확장성을 지원한다.
2. Stateless
서버는 클라이언트의 상태를 기억하지 않으며, 모든 요청을 독립적이어서 가시성, 확장성, 신뢰성이 향상된다.
3. Cache
응답을 캐싱할 수 있도록 하여, 네트워크 효율성과 사용자 경험을 개선한다.
4. Uniform Interface
일관된 인터페이스를 사용하여 컴포넌트 간 상호작용을 표준화하고, 독립적 발전을 가능하게 한다.
Uniform Interface의 제약 조건
- identification of resources
- manipulation of resources through representations
- self-descriptive messages
- hypermedia as the engine of application state (HATEOAS)
클라이언트가 서버 응답 내 하이퍼미디어 링크를 통해 자원 상태를 탐색할 수 있도록 한다. 이를 통해 클라이언트는 사전에 서버의 URI 구조를 알지 않아도 다양한 상호작용을 수행할 수 있다.
5. Layered System
계층 구조를 통해 보안, 캐싱, 확장성을 지원한다.
6. Code-On-Demand (Optional)
클라이언트가 코드를 다운로드하고 실행해 기능을 확장할 수 있지만, 가시성을 떨어뜨리기 때문에 선택적 제약 조건으로 적용된다.
REST의 의의
REST는 웹이 전 세계적 확장성과 지속 가능성을 갖춘 분산 아키텍처로 발전할 수 있도록 기여했으며, API 설계에서 자원 중심의 표준을 제시하며 다양한 서비스와 시스템 간의 상호 운용성을 높였다.
REST API
REST API(또는 RESTful API)는 REST 아키텍처 스타일의 설계 원칙을 준수하는 API로, 두 컴퓨터 시스템이 인터넷을 통해 데이터를 교환하기 위해 사용하는 인터페이스다. REST API는 HTTP 프로토콜을 기반으로 하며, 자원을 HTTP 메서드로 조작하여 다양한 시스템 간에 일관된 상호작용을 가능하게 한다.
REST API 설계 원칙
REST API는 기본적으로 다음과 같은 원칙을 따른다.
1. Identification of Resources - URI
모든 자원(Resources)은 URI(URL)를 통해 고유하게 식별된다. REST API에서 URI는 자원을 나타내는 중요한 요소로, 일관성 있는 URI 구조는 자원의 가독성과 사용성을 높인다.
2. Statelessness
REST API는 무상태성을 유지해야 한다. 클라이언트의 모든 요청은 독립적으로 처리되며, 각 요청에 필요한 모든 정보는 요청 자체에 포함되어야 한다. 이를 통해 서버는 클라이언트의 상태를 기억하지 않으며, 확장성과 관리가 용이해진다.
3. Uniform Interface - HTTP
REST API는 HTTP 통신 규약에 따라 클라이언트와 서버 간 일관된 상호작용을 정의한다. 이를 위해 HTTP 메서드와 HTTP 상태 코드를 사용하여 자원의 상태를 CRUD 방식으로 조작하고, 요청 결과를 명확히 전달한다.
HTTP Method
HTTP 메서드는 자원에 대한 작업을 정의하는 표준 동작 방식으로, GET, POST, PUT, PATCH, DELETE 등을 포함한다.
- GET: 자원의 조회
- POST: 자원의 생성
- PUT: 자원의 전체 수정
- PATCH: 자원의 일부 수정
- DELETE: 자원의 삭제
HTTP Status Code
HTTP 상태 코드는 요청의 성공 여부를 알리는 표준 코드로, 응답은 다섯 개의 그룹으로 나누어진다.
- Informational Responses (
100-199) - Successful Responses (
200-299)- 200 OK: 요청 성공
- 201 Created: 자원이 성공적으로 생성됨
- 204 No Content: 요청 성공, 반환할 데이터 없음
- Redirection Messages (
300-399) - Client Error Responses (
400-499)- 400 Bad Request: 잘못된 요청
- 404 Not Found: 요청한 자원을 찾을 수 없음
- Server Error Responses (
500-599)- Internal Server Error: 서버 오류
4. Representation
자원의 상태는 JSON, XML 등과 같은 표현 방식으로 전송된다. 표현은 자원의 데이터를 클라이언트에 전달하는 형식으로, 클라이언트가 자원을 이해하고 사용할 수 있게 한다. 대부분의 REST API에서는 JSON을 기본 형식으로 사용하여 데이터를 주고받는다.
마치며
REST의 개념과 등장 배경을 Roy T. Fielding의 논문을 바탕으로 정리했다. REST의 원칙을 잘 준수한 API는 확장성과 유지보수성을 높이고, 클라이언트와 서버 간의 일관된 상호작용을 가능하게 한다. 사실 대부분의 API는 REST보다는 HTTP API에 가까운 형태로 구현되곤 하는데, 이와 관련된 내용은 그런 REST API로 괜찮은가에서 확인해보자. REST API 설계 원칙을 고려해 더 견고하고 직관적인 API를 설계해보자!
References
Roy T. Fielding(2000). Architectural Styles and the Design of Network-based Software Architectures
[DEVIEW 2017] 그런 REST API로 괜찮은가
[NHN Cloud] REST API 제대로 알고 사용하기
