HTTP를 기반으로 클라이언트가 서버의 리소스에 접근하는 방식을 규정한
아키텍처
| 메서드 | 의미 |
|---|---|
| GET | 조회 |
| POST | 생성 |
| PUT | 전체 수정 |
| PATCH | 부분 수정 |
| DELETE | 삭제 |
REST를 기반으로 서비스 API 구현한 것
1) HTTP URI 를 사용
- 사용형식 : ‘/groups/:group_id’ 처럼 사용한다. (HTTP URI)
- URI 를 사용해 자원(데이터)에 진입할 수 있고, 데이터 조작하려면 Server에 요청한다
2) HTTP Method 사용
- 서버 연결시 HTTP 프로토콜의 Method를 사용
- URI 와 메소드로 CRUD 를 한다. (GET, POST, PUT, DELETE 메소드)
| 구성 요소 | 내용 | 표현 방법 |
|---|---|---|
| 자원(resource) | 자원 | URI(엔드 포인트) |
| 행위(verb) | 자원에 대한 행위 | HTTP 요청 메서드 |
| 표현(representations) | 자원에 대한 행위의 구체적 내용 | 페이로드 1 |
REST는 자체 표현 구조로 구성되어 REST API 만으로
HTTP 요청의 내용을 이해할 수 있다.
: REST의 기본 원칙을 성실히 지킨 서비스 디자인
쉽게말해서 Rest API 설계원칙대로 잘 짜여진 디자인을 Restful 이라고 한다.
그래서 Restful API 가 되기 위해서는 Rest API 설계원칙을 잘 지켜야한다.
REST에서 가장 중요한 기본적인 원칙은 두 가지다.
① URI는 리소스를 표현하는데 집중해야 한다
② 행위에 대한 정의는 HTTP 요청 메서드를 통해 해야 한다
위 두 규칙이 RESTful API를 설계하는 중심 규칙이다.
URI는 리소스를 표현하는 데 중점을 두어야 한다. 리소스를 식별할 수 있는 이름은 동사보다는 명사를 사용한다.
따라서 리소스 이름에 get 같은 행위에 대한 표현이 들어가서는 안 된다.
리소스에 대한 행위는 HTTP 요청 메서드로 표현한다
| HTTP 요청 메서드 | 종류 | 목적 | 페이로드 |
|---|---|---|---|
| GET | index/retrieve | 모든/특정 리소스 취득 | x |
| POST | create | 리소스 생성 | O |
| PUT | replace | 리소스의 전체 교체 | O |
| PATCH | modify | 리소스 일부 수정 | O |
| DELETE | delete | 모든/특정 리소스 삭제 | X |
리소스에 대한 행위는 HTTP 요청 메서드를 통해 표현하며 URI에 표현하지 않는다.
행위(HTTP 요청 메서드)를 통해 리소스에 대한 명확히 표시를 해야 한다.
bad
GET /todos/delete/1
good
DELETE /todos/1
클라이언트가 서버에게 요청을 보낼 때 이 요청들을 크게 4가지 성격으로 분류할 수 있다.
CRUD라고 불리는 이 4가지 대표적인 요청에 대해 살펴보자.
(1) Create = POST
- create는 서버에 정보를 올려달라는 요청이다. ( 생성 )
- create는 POST 메서드를 사용해 해당 URI를 요청하면 리소스를 생성한다.
(2) Read = GET
read는 서버에서 정보를 불러오는 요청이다. ( 읽기 )
read는 GET 메서드를 사용해 리소스를 조회하고 데이터를 가지고 온다.
(3) Update = PUT
- update는 정보를 바꾸는 요청이다. ( 수정 )
- update는 PUT 은 데이터 전체를 바꾸고 싶을 때, PATCH는 데이터의 일부만 수정하고 싶을 때 사용한다.
(4) Delete = DETELE
- delete는 정보를 지우는 요청이다. ( 삭제 )
- delete는 DELETE 메서드를 사용해 리소스를 삭제할 수 있다