REST(Representational State Transfer)란?
REST는 URI와 HTTP를 이용한, 통신 목적의 아키텍처 스타일을 말한다.
RESTful 하다고 하기 위해선, 다음의 6가지 조건을 만족시켜야 한다.
- 일관된 인터페이스 : 지정된 인터페이스를 준수한다. 그 인터페이스에는 URI 사용, HTTP 메소드 사용, Self-Descriptive Message, HATEOAS 등이 있다. 특히 뒷 부분 두 가지에 대한 설명을 아래에서 이어가겠다.
- 클라이언트/서버 : 클라이언트는 서버에 요청 메시지를 전송하고, 서버는 요청에 대한 응답 메시지를 전송한다. 서로 독립적이다.
- 비연결성 : 세션 등 이전 상황 없이도 통신할 수 있다. 클라이언트에서 서버로 가는 요청에는 그 요청에 필요한 모든 정보가 포함되어 있어야 한다.
- 캐시 가능 : 서버의 응답 메시지는 캐시가 가능한지 불가능한지 명시해야 한다.
- 계층화 된 시스템 : 계층 별로 기능이 분리되어, 중간 계층의 기능(로드밸런싱, 서버증설, 인증시스템 도입 등)이 변경되어도 통신 자체에 영향을 주지 않는다.
- 주문형 코드(선택) : 손쉬운 데이터 처리를 위해 서버는 클라이언트에서 실행될 스크립트를 전송할 수 있다.
Self-Descriptive Messages : API 메시지만 보고, API를 이해할 수 있는 구조 (Resource, Method를 이용해 무슨 행위를 하는지 직관적으로 이해할 수 있음)
HATEOAS : 서버는 현재 이용 가능한 다른 작업에 대한 하이퍼링크를 포함하여 응답해야 함
예를 들어, 아래와 같은 라떼 한 잔을 주문하는 post 요청이 있다.
POST https://api.examplebuks.org/orders HRRP/1.1
Content-Type : application/json
Content-Length : 33
{"drink":"latte", "quantity":1}
이에 대한 응답으로 서버는 클라이언트가 다음에 수행할 수 있는 것에 대한 정보를 제공한다.
{
"id" : 971103
"drink" : "latte",
"quantity" : 1,
"cost" : 1,
"status" : "pending",
"_links" : {
"self" : {
"href" : "https://api.examplebuks.org/orders/971103"
"type" : "GET"
},
"payment" : {
"href" : "https://api.examplebuks.org/payments/971103"
"type" : "PUT"
},
"update" : {
"href" : "https://api.examplebuks.org/orders/971103"
"type" : "PUT"
},
"cancel" : {
"href" : "https://api.examplebuks.org/orders/971103"
"type" : "DELETE"
}
}
}
HTTP 메소드란?
클라이언트와 서버 사이에 이루어지는 요청(Request)과 응답(Response) 데이터를 전송하는 방식을 일컫는다.
주로 사용되는 메소드는 다음과 같다.
- GET : 서버로 부터 데이터를 취득
- POST : 서버에 데이터를 추가, 작성 등
- PUT : 리소스를 대체(덮어쓰기), 해당 리소스가 없으면 생성
- PATCH : 리소스의 일부분을 수정
- DELETE : 서버의 데이터를 삭제
- HEAD : GET과 기본적으로 동일하나 body를 제외한 서버 리소스의 헤더와 상태줄만 반환한다.
- OPTIONS : 리소스가 지원하고 있는 통신 가능 옵션(메소드)를 설명
- CONNECT : 클라이언트와 서버 사이의 중간 경유를 위해 사용한다.
- TRACE : 대상 리소스에 대한 경로를 확인한다. 웹 서버로부터 받은 내용을 확인하기 위해 loop-back 테스트를 할 때 사용한다.
GET vs POST
- GET은 서버의 리소스에서 데이터를 요청할 때, POST는 서버의 리소스를 새로 생성하거나 업데이트할 때 사용한다.
- GET 은 URL 파라미터에 요청하는 데이터를 담아 보내기 때문에 HTTP 메시지에 body가 없다. POST 는 body 에 데이터를 담아 보내기 때문에 당연히 HTTP 메시지에 body가 존재한다.
- GET 방식은 요청 데이터가 그대로 url에 노출되므로 사용자가 쉽게 눈으로 확인할 수 있어 POST 방식보다 보안상 취약하다.
- GET 방식은 캐싱을 사용할 수 있어, GET 요청과 그에 대한 응답이 브라우저에 의해 캐쉬된다. 따라서 POST 방식보다 빠르다.
데이터를 조회하기 위한 용도로 POST가 아닌 GET 방식을 사용하는 이유는 무엇인가요?
설계 원칙에 따라 GET 방식은 서버에게 여러 번 요청을 하더라도 동일한 응답이 돌아와야 한다. (멱등성)
- GET 방식은 "가져오는 것"으로, 서버의 데이터나 상태를 변경시키지 않아야 한다.
(ex. 게시판의 리스트, 게시글 보기 기능 | 예외. 방문자의 로그 남기기, 글을 읽은 횟수 증가 기능) - POST 방식은 "수행하는 것"으로, 서버의 값이나 상태를 바꾸기 위한 용도이다.
(ex. 게시판에 글쓰기 기능)
웹에서 모든 리소스는 Link할 수 있는 url을 가지고 있어야 한다.
- 어떤 웹페이지를 조회할 때 원하는 페이지로 바로 이동하거나 이동시키기 위해서는 해당 링크의 정보가 필요하다.
- 만일 POST 방식을 사용한다면, 링크의 정보가 Body에 있기 때문에 url만 전달할 수 없으므로 GET 방식을 사용해야 한다. 글을 저장하는 경우에는 URL을 제공할 필요가 없기 때문에 POST 방식을 사용한다.
POST vs PUT
POST는 새로운 데이터를 계속 생성하기 때문에 요청시마다 데이터를 생성하지만, PUT은 사용자가 데이터를 지정하고 수정하는 것이기 때문에 같은 요청을 계속하더라도 데이터가 계속 생성되지는 않는다.
( POST 연산은 결과가 Idempotent하지 않지만, PUT은 반복 수행해도 그 결과가 Idempotent 하다.)
PUT vs PATCH
PUT은 지정한 데이터를 전부 수정하고, PATCH는 정보의 일부분이 변경되는 메소드다.
출처
'Computer Science > 네트워크' 카테고리의 다른 글
웹 통신의 흐름 (0) | 2023.03.13 |
---|---|
TCP와 UDP (1) | 2023.03.12 |
네트워크 계층 구조 (0) | 2023.03.12 |
CORS 에러 해결하기 (0) | 2023.03.09 |
HTTP와 HTTPS (0) | 2023.03.09 |