REST 개념, 구성 요소, 특징, 장단점

REST(REpresentational State Transfer)는 네트워크 상에서 Client와 Server 사이의 통신 방식 중 하나이다. 자원을 이름으로 구분하여 해당 자원의 상태(정보)를 주고받는 모든 것을 의미한다. 즉, 자원(resource)의 표현(representation)에 의한 상태 전달(state transfer)을 뜻한다.

• 자원 : 해당 소프트웨어가 관리하는 모든 것 ( 문서, 그림, 데이터, 해당 소프트웨어 자체 등 )
• 표현 : 그 자원을 표현하기 위한 이름 ( DB의 학생 정보가 자원이면, 'students'를 자원의 표현으로 정함 )
• 상태 전달 : 데이터가 요청되는 시점에 자원의 상태를 전달. ( JSON 혹은 XML을 통해 데이터를 주고 받는 것이 일반적 )

REST는 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에, ⭐웹의 장점을 최대한 활용⭐할 수 있는 아키텍처 스타일이다.

 

💡 개념

HTTP URI 를 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE) 를 통해 해당 자원에 대한 CRUD Operation(Create, Read, Update, Delete)을 적용하는 것을 의미한다.

• REST는 자원 기반의 구조(ROA, Resource Oriented Architecture) 설계의 중심에 Resource가 있고 HTTP Method를 통해 Resource를 처리하도록 설계되었다.
• 웹 사이트의 이미지, 텍스트, DB 내용 등의 모든 자원에 고유한 ID인 HTTP URI를 부여한다.

 

 

💡 구성 요소

1. 자원(Resource) - URI

• 모든 자원에는 고유한 ID가 존재하고, 이 자원은 Server에 존재한다.
• 자원을 구별하는 ID는 '/exgroups/:exgroup_id'와 같은 HTTP URI 이다.
• Client는 URI를 이용해 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server에 요청한다.

2. 행위(Verb) - Method

• HTTP 프로토콜의 Method를 사용한다.
• HTTP 프로토콜은 GET, POST, PUT, PATCH, DELETE의 Method를 제공한다. ( CRUD )

  GET	Read : 정보 요청, URI가 가진 정보를 검색하기 위해 서버에 요청한다.
  POST	Create : 정보 입력, 클라이언트에서 서버로 전달하려는 정보를 보낸다.
  PUT	Update : 정보 업데이트, 주로 내용을 갱신하기 위해 사용한다. (데이터 전체를 바꿀 때)
  PATCH	Update : 정보 업데이트, 주로 내용을 갱신하기 위해 사용한다. (데이터 일부만 바꿀 때)
  DELETE	Delete : 정보 삭제, (안전성 문제로 대부분 서버에서 비활성화한다.)

3. 표현 (Representation of Resource)

• Client와 Server가 데이터를 주고받는 형태로 JSON, XML, TEXT, RSS 등이 있다.
• JSON, XML을 통해 데이터를 주고 받는 것이 일반적이다.

 

 

💡 특징

1. Server-Client (서버-클라이언트 구조)

• 자원이 있는 쪽이 Server, 자원을 요청하는 쪽이 Client가 된다.
  • REST Server는 API를 제공하고 비즈니스 로직 처리 및 저장을 책임지고,
  • Client는 사용자 인증이나 context( 세션, 로그인 정보 ) 등을 직접 관리하고 책임진다.
  • 역할을 확실히 구분시킴으로써 서로 간의 의존성을 줄인다.

2. Stateless (무상태)

• HTTP 프로토콜은 Stateless Protocol이므로 REST 역시 무상태성을 갖는다.
• Client의 context를 Server에 저장하지 않는다.
  • 즉, 세션과 쿠키와 같은 context 정보를 신경쓰지 않아도 되므로 구현이 단순해진다.
• Server는 각각의 요청을 완전히 별개의 것으로 인식하고 처리한다.
  • 각 API 서버는 Client의 요청만을 단순 처리한다.
  • 즉, 이전 요청이 다음 요청의 처리에 연관되어서는 안된다. ( DB에 의해 바뀌는 것은 허용 )
  • Server의 처리 방식에 일관성을 부여하기 때문에 서비스의 자유도가 높아진다.

3. Cacheable (캐시 처리 기능)

• 웹 표준 HTTP 프로토콜을 그대로 사용하므로 웹에서 사용하는 기존의 인프라를 그대로 활용할 수 있다.
  • 즉, HTTP가 가진 가장 강력한 특징 중 하나인 캐싱 기능을 적용할 수 있다.
  • HTTP 프로토콜 표준에서 사용하는 Last-Modified Tag 또는 E-Tag를 이용해 캐싱을 구현한다.
• 대량의 요청을 효율적으로 처리할 수 있다.

4. Layered System (계층 구조)

• Client는 REST API Server만 호출한다.
• REST Server는 다중 계층으로 구성될 수 있다.
  • 보안, 로드 밸런싱, 암호화 등을 위한 계층을 추가하여 구조를 변경할 수 있다.
  • Proxy, Gateway와 같은 네트워크 기반의 중간매체를 사용할 수 있다.
  • 하지만 Client는 Server와 직접 통신하는지, 중간 서버와 통신하는지는 알 수 없다.

5. Uniform Interface (인터페이스 일관성)

• URI로 지정한 Resource에 대한 요청을 통일되고, 한정적으로 수행하는 아키텍처 스타일을 의미한다.
• HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하며, Loosely Coupling(느슨한 결함) 형태를 갖는다. 
  • 즉, 특정 언어나 기술에 종속되지 않는다.

6. Self-Descriptiveness (자체 표현)

• 요청 메시지만 보고도 쉽게 이해할 수 있는 자체 표현 구조로 되어있다.

 

 

💡 장단점

장점

• HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구축할 필요가 없다.
• HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해준다.
• HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.
• REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다.
• 서버와 클라이언트 역할을 명확하게 분리한다.

단점

• 표준이 존재하지 않는다.
• 사용할 수 있는 메소드가 4가지(HTTP Method) 뿐이다.
• 구형 브라우저에서 아직 제대로 지원해주지 못하는 부분(PUT, DELETE)이 존재한다.

 

참고 블로그 :

https://velog.io/@seokkitdo/Network-REST%EB%9E%80-REST-API%EB%9E%80-RESTful%EC%9D%B4%EB%9E%80

https://dev-coco.tistory.com/97