[Web] REST란? 메소드의 종류

 

REST란?

REST(Representational State Transfer)는 월드 와이드웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식으로 2000년 로이 필딩(R. Fielding)의 박사학위 논문(Architectural Styles and the Design of Network-based Software Architectures)에서 처음으로 소개된 개념이다. 쉽게 말하면 네트워크를 통해 공유되는 각각의 자원을 정의하고 자원에 대한 고유 주소를 지정하는 방법 전반을 일컫는 설계 지침 정도로 볼 수 있다.

본디 네트워크 톡신을 위해 제시하였으나, HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있을 뿐만 아니라 웹 기반의 데이터 전송을 위해 쓰이는 경우가 대부분이다.

 

REST의 특징

 

• Uniform Interface: URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처를 갖추어야 한다.

 

• Stateless : 무상태성. 작업을 위한 상태정보를 따로 저장하고 관리하지 않는다. 세션이나 쿠키를 사용하여 별도로 정보들을 저장하고 관리하지 않기 때문에 API 서버는 사용자로부터 들어오는 요청만을 단순히 처리한다. 따라서 서비스의 자유도가 높아지고 서버에서 불필요한 정보를 관리하지 않음으로써 구현이 단순하다.

 

• Cacheable : HTTP라는기존 웹 표준을 그대로 사용하기 때문에, 웹에서 사용하는 기존 기술들을 그대로 활용이 가능하다. 따라서 HTTP가 가진 캐싱 기능이 적용 가능하며, HTTP 프로토콜 표준에서 사용하는 Last-Modified태그나 E-Tag를 이용하면 캐싱구현이 가능하다. 이를 통해 확장성과 성능을 향상 시킬 수 있다.

 

• Self-Descriptiveness : REST API 메시지만 보고도 이를 쉽게 이해할 수 있는 자체 표현 구조를 지녀야 한다.

 

• Client - Server : REST 서버는 API 제공, 클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인 정보) 등을 직접 관리하는 구조로 각각의 역할이 확실히 구분된다. 따라서 클라이언트와 서버 간의 역할이 분명하며, 서로간의 의존성이 약해진 다.

 

• Layered System : 계층형 구조. REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조 상의 유연성을 둘 수 있고 proxy, 게이트웨이 같은 네트워크 기반의 중간 매체를 사용 할 수 있다.

 

Method

 

1. GET

리소스를 조회 또는 검색하기 위해 요청하는 메소드로 어떤 값이나 내용, 상태 등을 바꾸지 않고 리소스를 조회만 하는 경우에 사용한다.

GET 방식은 요청 조건이 담긴 데이터(예를 들면 seq, index 등)와 함께 Request할 경우 데이터를 Query Parameter를 통해 URL과 함께 요청한다. 쿼리 파라미터는 URL Parameter 또는 Query String 등으로도 칭한다. URL에 보내기 때문에 전송되는 데이터를 눈으로 확인할 수 있다.

또한 GET 방식은 기본적으로 RequestBody가 빈 상태로 보내지기 때문에 Header만 사용하여 송수신하는 경우가 많다. 물론 body를 사용하지 못하는 것은 아니다. 확인해 본 결과 2014년 이후로 GET 방식에서도 body를 사용할 수 있도록 변경되었다고 한다. 하지만 권장하지는 않는 것으로 보인다.

https://brunch.co.kr/@kd4/158

HTTP GET 메소드와 body

 

2. POST

POST 방식은 CRUD의 Create를 담당한다. 클라이언트가 서버로 데이터를 전송해 리소스를 추가하거나 생성하기 위해 사용하는 메소드이다.

POST 방식은 기본적으로 요청 시 GET방식과는 다르게 Body에 데이터를 담아서 보낸다. 따라서 보내는 데이터의 양에 대한 제한이 없어 대용량을 보낼 때도 적합하다.(데이터 전송을 기반으로 구성했기 때문)

또한 URL에 데이터가 표시되지 않기 때문에 GET 방식보다는 비교적 안전하다고 할 수 있지만 확인을 못 하는 것도 아니기 때문에 데이터의 보안성을 높이려면 별도의 암호화가 필요하다.

 

3. DELETE

지정된 리소스의 삭제를 요청할 때 사용하는 메소드이다. 안전성 문제로 비활성화 설정이 되어 있는 RESTful Server들이 있으므로 확인이 필요하다. 데이터를 삭제하는 것이 목적이기 때문에 Request 시 Body 값과 Content-Type 값이 비어져 있으므로 GET방식 처럼 어떤 데이터를 삭제하려는건지 조건 데이터를 URL과 함께 전송한다. 

 

4. PUT

리소스를 수정 또는 갱신(업데이트)을 요청할 때 사용하는 메소드이다. URL을 통해 seq 등 리소스를 특정하는 데이터를 전송하고 Body를 통해 데이터의 내용을 전송한다. 리소스가 존재한다면 갱신작업을 진행하고 리소스가 존재하지 않으면 생성작업을 한다. 쉽게 생각하면 Request 시 전송한 데이터로 덮어쓰는 것이라고 생각하면 된다.

 

5. PATCH

PUT 방식과 유사하게 요청된 자원을 수정할 때 사용하는 메소드이다. PUT 방식과의 차이점으로는 PUT방식의 경우는 Request 시 전송한 데이터로 리소스 전체를 갱신하지만 PATCH 방식은 리소스의 일부를 교체하는게 가능하다. 

 

6. HEAD

GET방식과 동일하지만, 응답에 BODY가 없고 응답 코드와 HEAD만 응답받는다. 주로 서버 정보 확인, 서버 Health Check, 서버 버전 확인 등 서버의 전반적인 정보를 확인하는 용도로 사용된다. 

 

7. CONNECT

CONNECT 방식은 REST CONNECT 방식이 구현된 외부 시스템 간의 터널링 또는 프록시 처리를 할 때 사용하는 메소드이다. HTTP 프록시 서버는 CONNECT 방식의 요청을 받게 될 경우 클라이언트와 주고받는 TCP 스트림을 프록시 처리함으로써 양방향 통신이 가능하게 만든다.

 

8. TRACE

특정 리소스의 루프백 테스트를 수행할 때 사용하는 메소드이다. 대상 리소스에 대한 루프백 경로를 응답하기 때문에 디버깅 시 사용된다. 

 

9. OPTIONS

RESTful Server에 적용된 통신 옵션을 요청할 때 사용하는 메소드이다. 

 

 

멱등성

멱등성은 수학이나 전산학에서 연산의 성질을 나타내는 것으로, 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질을 말한다. 즉, REST에서의 멱등성은 url을 여러번 호출 하더라도 항상 같은 결과가 발생할 경우 '멱등하다'고 할 수 있다.

 

멱등함	멱등하지 않음
GET, HEAD, OPTIONS, PUT, DELETE	POST, PATCH, CONNECT, TRACE

※올바르게 구현된 REST API일 경우 한정

 

• GET : 단순히 리소스를 조회하는 메소드이기 때문에 여러번 수행해도 결과가 바뀌지 않는다. 마찬가지로, HEAD와 OPTIONS 메소드도 조회에 대한 메소드이기 때문에 멱등하다.

 

• PUT : 리소스를 요청에 담긴 내용대로 통째로 대체해버리므로 올바르게 구현한다면 여러번 수행되어도 결과는 바뀌지 않는다.

 

• DELETE : 리소스를 삭제하는 메소드이기 때문에 리소스 삭제 시도에 대한 응답 코드와 이미 삭제된 리소스를 삭제하려는 시도에 대한 응답 코드는 다를 수 있겠지만, 리소스를 계속 삭제 시도한다고 해도 결과는 바뀌지 않는다.

 

• POST : 기본적으로 생성(CREATE)에 대한 메소드이기 때문에 동일한 리소스라도 여러번 시도에 대한 결과는 매번 바뀐다.

 

• PATCH : PATCH 메소드는 멱등할 수도 멱등하지 않을 수도 있다. 쉽게 말하면 멱등성을 보장하도록 설계할 수도 있고 멱등성을 보장하지 않게 설계할 수도 있다. PUT과 다르게 PATCH는 리소스의 일부에 대해 변경을 시도할 수 있기 때문이다.

 

 

Reference.

김현국, 박진태, 최문혁, 문일영.(2018).웹 애플리케이션 성능 분석을 위한 REST API 기반의 서버 구축.한국항행학회논문지,22(5),456-461.

https://www.botify.com/learn/basics/what-are-url-parameters