1. 개요
REST(Representational State Transfer)는 로이 필딩(Roy Fielding)이 자신의 2000년 박사 학위 논문에 정의한 네트워크 소프트웨어 아키텍처다. 쉽게 말하면 '네트워크에서 통신을 구성할 때 이런 구조로 설계하라는 지침' 정도로 볼 수 있다.본디 네트워크 통신을 위해 제시하였으나, 현실적으로 온라인 '네트워크'의 지분 중 태반을 차지하는게 월드 와이드 웹이기 때문에 '웹' 기반의 전송을 위해 쓰이는 경우가 대부분이다. 태생 자체가 데이터 송수신에 최적화 되어 있다보니 이를 위한 웹 API 쪽에서 굉장히 많이 쓰인다. 이를 'REST API'라고 부르는데, 이제는 그냥 '웹 API'와 동일하다고 볼 수 있을 정도로 보편화되었다. 어디선가 HTTP기반의 웹 API를 구현한다면 십중팔구는 REST를 준수하는 RESTful API라고 보면 된다.
대표적으로 Google을 포함하여, Facebook, 트위터, Naver, 카카오톡 등 IT 회사라면 각 회사의 서비스를 활용할 수 있는 REST API를 지원한다. 뿐만 아니라 OP.GG 같은 소위 '전적 사이트'들도 다 REST API를 기반으로 돌아가는 사이트들이다.
2. 조건
- Client-Server - 클라이언트와 서버로 분리되어야하며 서로 의존성이 없어야 한다.
- Stateless(무상태성) - 상태 정보를 따로 저장하지 않으며, 이용자가 누구인지 혹은 어디서 접근하는지와 관계 없이 결과가 무조건 동일해야 한다. 따라서 REST API는 필연적으로 오픈될 수밖에 없다.
- Cache - HTTP를 비롯한 네트워크 프로토콜에서 제공하는 캐싱 기능을 적용할 수 있어야 한다.
- Uniform Interface - 데이터가 표준 형식으로 전송될 수 있도록 구성 요소 간 통합 인터페이스를 사용한다. REST API 태반이 HTTP를 사용하기 때문에 HTTP 표준인 URL과 응답 코드, Request-Response Method 등을 사용한다.
- Layered System - API는 REST 조건을 만족하면 필연적으로 오픈될 수 밖에 없기 때문에, 요청된 정보를 검색하는데 있어 계층 구조로 분리되어야 한다.
- Self-descriptiveness - API를 통해 전송되는 내용은 별도 문서 없이 쉽게 이해할 수 있도록 자체 표현 구조를 지녀야 한다. 마찬가지로 웹 표준인 JSON과 XML이 절찬리에 사용중이다.
조건은 이렇지만, 현실적으로 '무상태성'을 가만히 놔두면 디도스 공격의 좋은 먹잇감이 되므로 실질적으로는 여러 인증 절차를 둬서 무분별한 이용을 막는 경우가 대부분이다. 이를 위해 OAuth 2.0(또는 OpenID)을 대표적으로 사용한다. 아래는 구글 API를 사용하는 OAuth 2.0 방법은 다양하게 존재하며 대표적으로 아래와 같이 구분할 수 있다#.
3. 용도
- Web server applications
- Client-side (JavaScript) applications
- Applications on limited-input devices
- Service accounts
4. 구성요소
4.1. 자원(Resource)
나무위키에서 몇가지를 예로 들자면,| URI | 의미 |
| https://namu.wiki/w/A | A 문서 조회 |
| https://namu.wiki/history/A | A 문서의 변경기록 조회 |
| https://namu.wiki/backlink/A | A 문서의 역링크 조회 |
| https://namu.wiki/edit/A | A 문서 수정 |
| https://namu.wiki/move/A | A 문서의 표제어 수정 |
| https://namu.wiki/delete/A | A 문서 삭제 |
여기서 /는 계층 관계를 나타낸다.
4.2. 메서드(Method)
HTTP 메서드를 사용한다.| POST | 자원 생성(Create) |
| GET | 자원 조회(Read) |
| PUT | 자원 수정(Update) |
| DELETE | 자원 삭제(Delete) |