REST(Representational State Transfer)

 

웹서비스는 초기 SOAP, XML, WSDL, UDDI를 기반으로 웹 기반 응용을 통합하는 표준방법을 주로 사용했습니다.

하지만 현재는 XML기반 표준이 처리하기 무겁고 복잡해서, 상대적으로 가볍게 처리가 가능한 RESTful API와 JSON 기반으로 웹서비스 기술이 발전하고 있습니다.

(XML이 궁금하시다면, 여기서 확인하세요↓)

XML(extensible markup language)

 

오늘은 SOAP과 함께 자주 언급되는 REST에 대해 알아보도록 하겠습니다.

​

---

 

SOAP은 비즈니스 플로(business flow) 처리에서 주로 사용됐다면, REST는 데이터 접근에서 주로 이용됩니다.

(SOAP이 궁금하시다면, 여기서 확인하세요↓)

SOAP(Simple Object Access Protocol)

 

 

REST(Representational State Transfer)

 

출처 : https://www.namasteui.com/what-is-the-difference-between-api-and-rest-api/

 

REST는 클라이언트와 서버 간에 데이터를 주고받는 간단한 방법입니다.

시스템이 서로 더 쉽게 통신할 수 있도록 하는 아키텍처 스타일입니다.

웹의 장점을 최대한 활용할 수 있는 아키텍처로, 웹상의 자료를 HTTP 위에서 SOAP이나 쿠키를 통한 세션 트랙킹 같은 별도의 전송 계층 없이 전송하는 아주 간단한 인터페이스입니다.

(HTTP가 궁금하시다면, 여기서 확인하세요↓)

HTTP와 HTTPS

 

즉, 데이터를 HTTP에서 부가적인 전송 레이어없이 전송하기 위한 인터페이스입니다.

REST가 매우 가볍고 간단해서, SOAP의 복잡성과 비교되어 많이 언급됩니다.

​

REST는 자원 지향 아키텍처를 구현하며, 여기서 자원은 재사용가능한 소프트웨어 구성요소를 말합니다.

​

REST 아키텍처 스타일을 따르는 웹서비스를 Restful 웹서비스라고 부릅니다.

 

 

RESTful

 

REST가 적용된 시스템으로 REST API를 제공하는 것을 RESTful하다고 합니다.

REST를 REST답게 쓰기 위한 방법으로, 누군가가 공식적으로 발표한 것은 아니지만 여러 개발자들이 비공식적으로 의견을 제시한 것들입니다.

​

RESTful하기 위해서는 아래 제약 조건을 만족해야합니다.

 

Client-Server Architecture	클라이언트 : 로그인 정보 관리, 서버 요청 메시지 전송 서버 : 자원 관리, 요청에 대한 응답 메시지 전송 클라이언트-서버의 각 파트가 독립적으로 개선될 수 있음
Stateless(비연결성)	세션 등 이전 상황 없이도 통신 가능
Cacheable(캐시 처리 가능)	서버의 응답 메시지를 저장하고 재사용 가능 캐시 가능은 동일한 후속 요청에 대한 응답으로 재사용 가능 (HTTP 웹 표준을 사용하기 때문에 HTTP가 가진 캐싱 기능 활용)
Uniform interface(일관된 인터페이스)	지정된 인터페이스 준수 (URI 사용, HTTP 메서드 사용, RPC 미호출 등)
Layered system(계층화)	계층별로 기능 분리 중간계층의 기능이 변경되어도 통신에 영향을 주지 않음 (서버 증설, 인증 시스템 도입 등)
Code on demand(주문형 코드)	손쉬운 데이터 처리를 위해 서버는 클라이언트에게 실행될 스크립트를 전송할 수 있음 (클라이언트의 기능을 일시적으로 확장)

 

RESTful의 명확한 정의는 없지만, 이해하기 쉽고 사용하기 쉬운 REST API를 만들기 위함이 RESTful의 목적입니다.

​

 

REST 장점

 

1. HTTP 프로토콜의 인프라를 그대로 사용하므로, REST API 사용을 위한 별도의 인프라가 필요 없습니다.

​

2. HTTP 프로토콜의 표준을 최대한 활용하여, 여러 추가적인 장점을 함께 가져갑니다.

​

3. HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능합니다.

​

4. REST API 메시지가 의도하는 바를 명확하게 나타내므로, 의도하는 바를 쉽게 파악할 수 있습니다.

​

5. 서버와 클라이언트의 역할을 명확하게 분리하기 때문에, 확장성이 좋습니다.

​

6. 개발이 단순하여 도구가 거의 필요 없습니다.

​

7. 추가적인 메세징 계층이 없습니다.

​

​

REST 단점

 

1. 사용할 수 있는 메소드가 제한적입니다.

   (HTTP Method 형태가 제한적입니다.)

​

2. 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 값이 더 어렵습니다.

​

3. 구형 브라우저가 아직 제대로 지원해주지 못하는 부분이 존재합니다.

   (PUT, DELETE를 사용하지 못하는 점과 pushState를 지원하지 않는 점)

​

4. 보안, 정책 등에 대한 표준이 없어서, 관리가 어렵습니다.

​

5. point-to-point 통신 모델을 가정하기 때문에, 둘 이상이 상호작용하게 되는 경우에는 유용하지 않습니다.

​

​

​

 

---

[참고 자료]

TTA정보통신용어사전

 

REST - 위키백과, 우리 모두의 백과사전

 

레스트풀 - 해시넷

---