💡 REST
REpresentational State Transfer : 자원의 표현(이름)에 의한 상태(데이터) 전달
-
월드 와이드 웹(www)과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 개발 아키텍처의 한 형식 : HTTP 프로토콜 사용 → HTTP URI를 통해 자원을 명시하고, HTTP Method를 통해 해당 자원에 CRUD 처리
-
HTTP URI : 자원의 표현 (이름) → 클라이언트는 URI를 통해 서버에 자원에 대한 처리를 요청함
-
HTTP Method : 자원에 대한 처리 (CRUD Operation)
- POST = CREATE : 생성
- GET = READ : 조회
- PUT/PATCH = UPDATE : 완전/일부 수정
- DELETE = DELETE : 삭제
-
-
⭐ 스마트폰이 급성장하게 되면서, 서버는 웹 브라우저 외에 모바일(안드로이드) 기기와 같은 다양한 클라이언트와 통신해야 하는 상황에 직면하게 된다. 이 때 HTTP 프로토콜을 따르는 플랫폼이라면 REST 방식을 사용하여 특정 언어나 기술에 종속되지 않고 통신할 수 있다.
📝 특징
- server - client 구조
- server : 리소스를 가지고 있는 쪽 → API 제공 및 비즈니스 로직 처리
- client : 리소스를 요청하는 쪽 → context 관리
- Stateless : 무상태 (서버는 클라이언트의 상태를 보존하지 않음)
: HTTP 프로토콜은 무상태이므로 HTTP 프로토콜 기반인 REST 또한 무상태이다.
- Chaceable : 캐시 처리 가능
: HTTP 프로토콜에서 사용하는 Last-Modified, E-Tag 등을 사용하여 캐싱을 구현할 수 있다. 캐시를 사용하면 응답시간이 빨라져 API의 성능을 향상시킬 수 있다.
📒 REST API
REST 기반으로 서비스 API를 구현한 것
- API (Application Programming Interface) : 운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스 → 애플리케이션을 연결하여 서로 통신하는 것
: 하나의 API를 웹, 모바일 등 여러 시스템에서 사용함으로써 확장성 및 재사용성이 높아진다.
📝 설계 규칙
- URI : 리소스 표현 → 소문자, 복수 명사 권장
ex) 특정 회원 조회 : GET /members/{id}
- HTTP Method : 리소스에 대한 행위 표현 → URI에는 되도록이면 동사를 사용하지 않는다.
ex) 특정 회원 삭제 : DELETE /members/{id}
➕ REST API가 아닌 HTML Form의 경우, GET/POST만 지원하므로 필요에 따라 동사인 컨트롤 URI를 사용할 수도 있음 → POST /members/{id}/delete
- 슬래시
/는 계층 관계를 나타냄 : 하나의 리소스를 전달해야 하므로 URI의 마지막에/를 사용하지 않는다.
ex) GET /members/ ❌ → GET /members ⭕
- 리소스 간 연관관계가 있는 경우,
/리소스명/리소스ID/연관된 리소스명형식으로 표현
ex) 특정 회원이 작성한 모든 게시글 조회 : GET /members/{id}/posts
- 파일 확장자는 URI에 포함하지 않는다. → 헤더 (Accept) 사용
ex) GET /members/image.jpg ❌ → GET /members + Accept: image/jpg ⭕
✔️ REST API 설계 예시
| Example | HTTP Method | REST API |
|---|---|---|
| 모든 회원 조회 | GET | /members |
| 특정 회원 조회 | GET | /members/{id} |
| 회원 저장 | POST | /members |
| 특정 회원 수정 | PUT | /members/{id} |
| 특정 회원 삭제 | DELETE | /members/{id} |
: 실제로 사용된 URI는 /members, /members/{id} 2개이지만, HTTP Method를 통해 각 작업을 구분하여 다양한 작업을 처리할 수 있다!
🙇🏻♀️ 참고 : [Network] REST란? REST API란? RESTful이란?
