REST
REST ?
- Representational State Transfer
- 자원을 이름으로 구분하여 상태(정보)를 주고 받는 것
- 자원(resource)의 표현(representation)에 의한 상태 정보 전달
자원
- 소프트웨어가 관리하는 모든 것 (ex) 문서, 그림, 데이터 등)
표현
- 자원을 표현할 수 있는 이름 (ex) db 중, 학생 정보 =>
students)
상태(정보) 전달
- 데이터 요청 시점에 정보가 전달된다.
- 일반적으로
JSON, XML를 통해 송수신
WWW (World Wide Web)과 같은 분산 하이퍼 미디어 시스템을 위한 SW 개발 아키텍처
- 기존 웹 기술 +
HTTP을 그대로 활용하기 때문에 웹의 장점을 최대한 활용 가능
구체적인 개념
HTTP URI를 통해 자원을 명시하고 HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD를 적용하는하는 것
- CRUD
- 생성(Create,
POST)
- 조회(Read,
GET)
- 수정(Update,
PUT)
- 삭제(Delete,
DELETE)
- 헤더 정보 조회(HEAD,
HEAD)
- REST = 자원 기반 구조 (ROA, Resource Oriented Architecture) 설계의 중심에
자원(Resource)이 있고 HTTP Method를 활용하여 자원을 처리한다.
장 / 단점
- 장점
- HTTP를 그대로 사용하기 때문에 별도로 REST API 인프라를 구축할 필요가 없다.
- HTTP를 사용하는 모든 플랫폼에서 사용 가능
- 범용성 보장 (HyperMedia)
- 메시지가 의도하는 바를 명확히 표현 가능
- 서버와 클라이언트의 역할을 명확히 구분
- 단점
- 표준이 존재하지 않는다.
- 메소드는 HTTP Method로 국한된다.
- 구형 브라우저에서 지원하지 않는
PUT, DELETE
필요성
- 애플리케이션의 분리 및 통합
- 다양한 클라이언트 종류
- 다양한 모바일 및 웹 클라이언트와 소통이 가능하다.
⭐️ 구성 요소
자원 (Resource) : URI (Uniform Resource Identifier)
- 모든 자원은 고유의 식별자 값(ID)이 존재하며, 서버에 담긴다.
- ID의 형태는
/a/a_id와 같이 URI의 형태
- 클라이언트는 URI를 통해 자원을 지정하고, 서버에게 자원에 대한 조작을 요청
행위 (Verb) : HTTP Method
- HTTP Method(
POST, GET, PUT, DELETE 등)를 필요에 따라 사용하여 서버에게 요청
표현 (Representation)
- 클라이언트가 자원을 조작하는 요청을 보낼 때, 서버는 응답한다.
- 보통,
JSON, XML, TEXT, RSS 등으로 자원이 표현된다.
특징
- 서버 - 클라이언트
- 자원을 갖는
Server, 자원에 대한 조작을 요청하는 Client
- Server : API를 제공한다. 비즈니스 로직 담당
- Client : 사용자 정보(
context)를 관리하고 책임진다.
- 서로의 의존성 감소
- Stateless (무상태)
- HTTP이 Stateless -> REST도 Stateless
- 클라이언트의 context(쿠키, 세션 등)을 서버에 저장하지 않는다.
- 서버는 클라이언트의 각 요청을 별개로 인식하고 처리
- 전 요청이 후 요청에게 연관되어서는 안된다.
- DB를 수정하여 DB에 의해 의한 수정은 허용
- 일관성, 자유도 상승
- Cachable
- HTTP 인프라를 그대로 사용하므로 캐싱 기능 또한 가능하다.
Last-Modified 태그나 E-Tag를 이용하면 캐싱 구현이 가능하다.
- 대량 요청을 처리하기 위함
- 계층화 (Layered System)
- 클라이언트는 서버의 REST API만을 호출
- 서버를 다중 계층으로 구성할 수 있다.
- 비즈니스 로직을 처리하는 서버
- 그 앞단에 보안, 로드 밸런싱 등을 통해 시스템의 유연성과 확장성, 보안성을 상승시킬 수 있다.
- 인터페이스 일관성
- 자원 조작은 한정적이고 일관적인 인터페이스를 통해 조작된다.
- HTTP 표준을 사용하는 모든 플랫폼에서 사용 가능
REST API
REST API ?
- API (Application Programming Interface)
- 데이터와 기능의 집합을 통해 정보를 교환한다.
- REST API
- REST 기반의 API
- 특히, 현대의 OpenAPI 및 마이크로서비스 아키텍처에서 주로 사용된다.
특징
- 확장성과 재사용성을 높여 유지보수가 유연해진다.
- HTTP를 지원하는 클라이언트, 서버 애플리케이션을 구현할 수 있다.
⭐️ 설계 규칙
- Document : 객체의 인스턴스, 데이터베이스의 레코드
- Collection : 서버에서 관리하는 Directory(자원)
- Store : 클라이언트에서 관리하는 자원 저장소
기본
URI는 자원의 정보를 표현하자 !
- 동사 -> 명사 / 대문자 -> 소문자
- Document -> 단수 명사
- Collection -> 복수 명사
- Store -> 복수 명사
- ex)
GET /Member/1 -> GET /members/1
- 행위는
HTTP Method로 표현하자 !
- URI에 메소드를 표현하지 말자
- ex)
GET /members/delete/1 -> DELETE /members/1
- URI 행위에 대한 동사를 넣지 말자
- ex)
GET /members/show/1 -> GET /members/1
- 변하는 부분은 유일한 값(ID)로 표현하자
- ex) student 생성
POST /students
- ex) 특정 student 삭제
DELETE /students/1
심화
/는 계층 관계를 표현
- ex)
http://restapi.ex.com/names/last
- 특히, 마지막에는 넣지 않는다.
-(하이픈)은 가독성을 위해 사용, _(언더 라인)은 사용하지 말자
- URI 경로는 소문자
- 파일 확장자는 URI에 포함하지 않는다.
Accept Header를 사용한다.
- ex)
http://restapi.ex.com/names/last/1/img.jpg (X)
- ex)
GET /names/last/1/img HTTP/1.1 HOST:restapi.ex.com Accept: image/jpg (O)
- 리소스간 연관관계가 있는 경우는 아래처럼 하자.
/리소스/리소스 ID/관계된 다른 리소스
- ex)
GET /members/1/devices
예시
| 설명 (CRUD) | HTTP Method | 경로 |
|---|
| 모두 조회 | GET | /resources |
| 단일 조회 | GET | /resources/:id |
| 생성 | POST | /resources |
| 수정 | PUT | /resources/:id |
| 삭제 | DELETE | /resources/:id |
(참고) 응답 상태 코드
1xx : 전송 프로토콜 수준의 정보 교환
2xx : 요청 성공
3xx : 클라이언트는 요청을 위해 추가적으로 행동을 취해야 함
4xx : 잘못된 요청
5xx : 서버 오류
RESTful
RESTful ?
RESTful하다. = REST API를 제공하다.
- 공식적인 것이 아니다. REST를 REST 답게 쓰기 위함.
목적
- 이해와 사용이 쉬운 REST API를 만들기 위함
- RESTful 한 API 구현은 성능 향상이 목적이 아니라, 일관된 컨벤션을 통한 유연성과 호환성을 높이기 위함이다.
RESTful 하지 않다.
- CRUD를 모두 POST만 사용할 때
- URI 경로에
resource, id외의 정보가 들어가있을 때
- ex)
PUT /users/updatedName
출처 : Heee's Development Blog