Representational State Transfer API
정의
API
Application Programming Interface
- 다른 디바이스가 서로 간에 연결하여 통신할 수 있는 방법을 정의하는 규칙 세트
- 하나의 Application에서 다른 Application 내의 리소스에 엑세스할 수 있도록 해주는 매커니즘
REST 아키텍쳐
REpresentational State Transfer
- Roy Fielding 박사가 2000년에 자신의 박사학위 논문에서 처음 정의.
- 한글로 표현하자면 대표적인 상태 전달
REST 제약 조건
균일한 인터페이스
- 요청이 어디서 오는지와 무관하게, 동일한 리소스에 대한 모든 API 요청은 동일하게 보여야 한다.
- 사용자의 이름이나 이메일 주소 등의 동일한 데이터 조각이 오직 하나의
URI(Uniform Resource Identifier)에 속함을 보장해야 한다.
URI ( Uniform Resource Identifier )
통합 자원 식별자
웹 기술에서 사용하는 논리적 또는 물리적 리소스를 식별하는 고유한 문자열 시퀀스
scheme:[//[user[:password]@]host[:port]][/path][?query][#fragment]
URL ( Uniform Resource Locator )
통합 자원 위치, URI의 일종이다
컴퓨터 네트워크 상에서 리소스가 어디 있는지 알려주기 위한 규약
- 리소스가 너무 클 필요는 없지만, 이는 클라이언트가 필요로 하는 모든 정보를 포함해야 한다.
클라이언트 - 서버 디커플링
- 클라이언트와 서버 Application은 서로 간에 완전히 독립적이어야 한다.
- 클라이언트에서는 요청된 리소스의 URI만 알아야한다.
- 서버에서는 HTTP를 통해 요청된 데이터에 전달하는 것 말고는 클라이언트와 상호작용하지 않는다.
Stateless (무상태성)
- 각 요청에서 이의처리에 필요한 모든 정보를 포함해야 함.
- 클라이언트는 서버측 세션을 필요하지 않는다.
- 서버는 클라이언트 요청과 관련된 데이터를 저장할 수 없다.
캐싱 가능성
- 가급적이면, 리소스를 클라이언트 또는 서버에서 캐싱할 수 있어야 한다.
- 서버 응답에는 전달된 리소스에 대해 캐싱이 허용되는지 여부에 대한 정보도 포함되어야 한다.
계층 구조 아키텍처
- Request와 Response가 서로 다른 계층을 통과한다.
- End-Point또는 Router와 통신하는지 여부를 클라이언트나 서버가 알 수 없도록 설계되어야한다.
코드 온디맨드(옵션)
- 일반적으로 정적 리소스를 전송하지만, 특정한 경우에는 Response에 실행 코드를 포함할 수 도 있다.
REST API 설계
Method
| Method | 기능 |
|---|---|
| GET | 조회 |
| POST | 데이터 생성 |
| FETCH | 데이터의 일부 요소를 업데이트 |
| PUT | 데이터의 모든 요소를 업데이트 |
| DELETE | 데이터 삭제 |
중심 규칙
URI 만 보고도 해당 기능의 핵심을 바로 파악할 수 있어야 한다.
- URI는 정보의 자원을 표현해야 한다.
- 자원에 대한 행위는 HTTP Method로 표현한다.
주의 사항
- SQL Query에 존재하는 키워드의 사용을 자제한다.
- 슬래시 구분자(
/)는 계층 관계를 나타내는데 사용한다. - URI 마지막 문자로
/를 포함하지 않는다. - 하이픈(
-)은 URI 가독성을 높이는데 사용한다. - 언더바(
_)는 URI에 사용하지 않는다. - URI 경로에는 소문자가 적합하다.
- 파일 확장자는 URI에 포함하지 않는다.
- Accept Header를 사용하자
Example
- 모든 유저를 조회한다.
- GET /users
- 1번 유저를 삭제한다.
- DELETE /users/1
- 1번 유저의 친구 목록을 조회한다.
- GET /users/1/friends
- 1번 유저가 좋아하는 디바이스 목록을 조회한다.
- GET /users/1/likes/devices
URL
백엔드 개발자 지망생