REST, RESTful

REST, RESTful

 

REST Architectrue에 대해 공부한 내용을 기록한 글입니다.

 

REST Architectrue

- HTTP Web Service

- RESTful API Web Service

 

1. REST & SOAP & HTTP

2. HTTP Web Service의 개요와 RESTful Web Service란 무엇인가

3. REST란?

---

1. REST & SOAP & HTTP

 

# REST와 SOAP의 차이점

- SOAP : 공식 표준의 웹 통신 방식으로 XML 방식으로 DATA를 교환한다.

- REST : 사실상 표준(2000년), 보편적으로 사용되는 웹 통신 방식으로 JSON 방식으로 DATA를 교환한다.

둘 다 HTTP PROTOCOL을 사용한다는 공통점이 있다.

 

 

 

# HTTP request / response 모델

Client - - - Request - - - > Web Server

Client < - - - Response - - - Web Server

 

클라이언트(Client)는 대게 웹 브라우저이고, 클라이언트의 요청(Request)을 받은 웹 서버(Web Server)는 요청을 해석해 클라이언트에 응답(Response)한다.

 

최근 http 통신을 안 쓰이는 곳은 거의 없다고 한다. Server와 DB간의 통신은 주로 드라이버를 통해서 통신을 하는데 근래 Elastic Search를 읽기 전용 DB로 보는데 이는 데이터베이스의 http 통신을 활용하는 예시가 된다. 앞으로는 더 http 통신을 많이 사용하게 될 것으로 전망한다고 한다.

 

 

 

# HTTP Message

HTTP Message는 Header, Body 등으로 구성되어 있으며 Header에는 요청 방식 등 메타데이터가 담겨 있고, Body에는 Data가 담겨 있다.

 

 

 

# HTTP Methods

HTTP 요청 방식이 정해져 있다.

클라이언트 요청의 종류에 따라 서버는 이 정보를 통해 적당한 응답을 제공한다.

Method	Description
GET	자원 요청
POST	Entity를 포함한 자원 요청
HEAD	HTTP Header 정보만 수신
TRACE	Request의 루프백 테스트
PUT	URL에 자원을 생성
DELETE	URL의 자원을 삭제
OPTIONS	응답 가능한 HTTP 메서드를 요청
CONNECT	터널링의 목적으로 연결 요청 (프록시에서 사용함)

 

 

 

# URL - 식별자로 사용

컨텐츠에 접근하기 위한 위치 정보

 

https://abc.com/index.html 

 

https : protocol

abc.com : server

index.html : resource

 

 

---

2. HTTP Web Service의 개요와 RESTful Web Service란 무엇인가

 

# RESTful 기반 웹 서비스

 

Roy Fielding 박사학위 논문에서 제안되었다. (2000년)

 

웹 아키텍처(Web Architecture)가 웹의 본래 설계의 우수성을 활용하지 못하므로 웹의 장점을 최대한 활용할 수 있는 네트워크 기반의 아키텍처를 제안

 

 

 

# 데이터가 중요해짐

소프트웨어는 대체되어도 수년간 쌓인 데이터는 대체할 수 없다. 현재 데이터는 더 중요해지고 있다.

데이터는 빅데이터 등 더 활용 가치가 높아짐

 

SOAP : 동작과 프로세싱에 집중

REST : 데이터 처리 중심

 

(스프링 3.0부터 REST 작업에 대한 최고 수준의 지원을 제공하고 있음)

 

 

 

# RESTful 기반 웹 서비스

RESTful 웹 서비스 (Representational State Transfer, 2000s)

 

- HTTP Protocol로 Data를 전달하는 Framework

- 핵심은 Web에 개발된 Resource를 이용

 

REST Architecture 스타일에 따라 정의되고 이용됨

 

- REST API : 소유자의 자원에 접근할 수 있는 API

- RESTful 하다 : REST API를 제공하는 웹 서비스

 

 

# REST는 웹 서비스의 사실상 표준이다.

# 스프링과 스프링부트는 REST를 적극적으로 지원한다.

 

 

 

---

3. REST란?

 

# REST란 무엇인가?

 

- 2000년에 HTTP 프로토콜 저자 중 한명인 Roy Fielding 박사 논문에 소개

- 기존 웹 서비스들이 HTTP를 적극적으로 활용하지 못한 문제를 해결하기 위해 제안됨

- HTTP를 보다 HTTP 답게 만들기 위한 방법론으로 볼 수 있음

- 철저히 Resource 중심적 설계를 중요시하고,

 ▶ Create - POST

 ▶ Read - GET

 ▶ Update - PUT

 ▶ Delete - DELETE

 와 같이 HTTP 4가지 Method를 용도에 맞게 사용

- 오늘날 Google, Amazon, Flickr, Tweeter 와 같은 Open Source 업체들의 주도 하에 적극 적용되어, De-facto Standard로 자리잡음

 

 

 

# REST 원리 및 원칙 (제약조건)

확장성 있는 웹 서비스를 위한 소프트웨어 아키텍처 적인 접근

 

Client-Server

 

Stateless (무상태)

 - 클라이언트의 상태를 서버에 저장하지 않음 (확장성)

ㄴ>  요청이 동일하면, 응답도 동일해야한다.

 

Cacheable

 

Layered system

 

Code on demand (optional)

 

Uniform interface

 - REST의 코어인 리소스는 URI에 의해 식별됨

 - 데이터 구조(data representation)는 강제하지 않음 (주로 XML 또는 JSON)

 

 

 

# Client-Server

Client를 Server로부터 분리

- View와 Data를 분리

- Portability(이동성)를 향상

- REST 서버는 Resource를 관리하는 API를 제공

 ▶ 클라이언트는 사용자 인증이나 Context(Session, Login 정보) 직접 관리

 ▶ 서버는 UI나 User State에 상관없이 Server 기능에 집중 (단순화, 확장성)

 ▶ Data만 응답

 

 

 

# Stateless 

세션정보와 같은 context를 저장할 필요가 없음

동일한 요청에 동일한 응답

클라이언트는 자신을 구분하기 위해 서버에게 충분한 정보를 전달해야 함

 - API Key 또는 Token

 

Stateless

- No session

- No login and has no basket

- Static content

 

Stateful

- session

- Logged in or has a basket

- Dynamic content

 

 

 

# Cacheable

HTTP Protocol의 Caching 기능을 적용할 수 있음

 - 웹 서비스의 60~80%가 GET 방식의 요청

 - 구현은 HTTP 프로토콜 표준인 'Last-Modified' 태그나 E-Tag를 이용

 

브라우저, WAS, Web Server 등에서 캐시를 더 효율적으로 사용해 서비스의 성능을 높일 수 있다.

같은 요청에 대해서 같은 응답이면 캐시를 사용해 요청을 최소화시켜 성능을 높인다.

 

 

 

# Layered System

시스템 스케일링을 위해 Gateway, Proxt Server, Firewall 과 같은 또 다른 Layer들을 수용할 수 있음

 

 

 

# Code on Demand (Optional)

※ 최근에 잘 안 쓰임

 

서버는 실행 가능한 코드를 클라이언트에게 전송

- 클라이언트의 기능을 일시적으로 확장하거나 커스터마이징 가능

- Java Applet, JavaScript가 대표적 예

 

 

 

# Uniform Interface

REST 디자인 constraints에서 가장 기본적인 제약

통일된 인터페이스(URI)를 통해 기술과 플랫폼에 상관없이 사용 가능

Uniform Interface는 다음 4가지로 설명할 수 있음

◆ Resource Identifier

◆ Resource Representations

◆ Self-Descriptive Message & API

◆ HATEOAS (Hypermedia As The Engine Of Application State)

 

 

◆◆◆ Resource Identifier - URI

Resource는 서비스나 정보를 제공하는 모든 것들이 될 수 있음

- 주문, 송장, DB의 레코드, 검색 결과 등

- 웹 상에서 주소를 통해 접근 될 수 있음. 즉, 리소스는 URI를 반드시 가져야 함

- URI 정의는 동사형이 아닌 명사형으로 정의하도록 권장됨

 

https://www.abc.com:80/index.php?url=url#anchor

 

 

 

◆◆◆ Resource Representations이란 무엇인가?

Resource는 Unique ID로 하나 이상의 URI 뿐만 아니라, 다양한 방법으로 설명(대표)되는 Representation을 가질 수 있음

- Representation에 대한 접근을 위한 URL을 가지고

- HTTP 4가지 메서드(POST/GET/PUT/DELETE)를 통해 CRUD 할 수 있음

 

URL > Resource > Representation > URL (GET / POST / PUT / DELETE)

 

하나의 URL을 선택하더라도 다양한 결과를 얻을 수 있다. 같은 리소스를 처리하더라도 http 메서드에 따라 응답이 달라질 수 있다. http 메서드가 리소스에 대한 처리의 차이를 나타낼 수 있어 리소스의 Representation이라 할 수 있다.

 

 

[GET] https://example.org/greeting

위와 같은 URL 요청할 떄 http 메서드를 선택해 서버에 요청한다.

서버가 보내준 것은 Resource가 아니라 Representation 이다. http 메서드에 따라 Representation이 다르다.

 

 

HTTP에서의 Representation

GET 메서드 정의

The GET method requests transfer of a current selected representation for the target resource.

- Target resource에 대한 현재의 선택된 representation 하나를 반환함

- 리소스는 HTTP 요청의 대상이지만, 리소스의 개념을 제한하지 않음

 

Representation 이란?

어떤 리소스의 특정 시점의 상태를 반영하고 있는 정보

다음 두 가지로 구성됨

- Representation data

- Representation metadata

 

 

Representation 사례

영어 사용자와 한국어 사용자를 위한 representation 

 

똑같은 리소스를 요청했을 때 다른 응답을 보여주는 사례

 

use case 1

Content-Type : text/plain
Content-Language : en

hello

use case 2

Content-Type : text/plain
Content-Language : ko

안녕하세요

use case 3

Content-Type : text/html; charset=UTF-8
Content-Language : en

<html><body>hello</html></body>

use case 4 

Content-Type : text/html; charset=UTF-8
Content-Language : ko

<html><body>안녕하세요</html></body>

- 클라이언트와 서버 간의 내용 협상(Content negotiation)을 통해 선택 됨

- 일반적으로 사전 협상(proactive negotiation)에 의해 서버가 선택

- 적절한 representation이 존재하지 않는다면 406 Not Acceptable로 응답

- URI 가 동일하다면 같은 리소스임

 

 

 

◆◆◆ Self-Descriptive Message & API

REST는 Stateless (상태가 없다.)

 

클라이언트 - 서버 간 충분한 설명적인 메시지가 필요하다.

- HTTP 메서드

- HTTP 상태 코드

- HTTP 헤더

 

 

 

◆◆◆ HATEOAS

Hypermedia As The Engine Of Application State

- HATEOAS 메시지를 보내는 것은 애플리케이션의 상태를 변화시킴

- HTTP 응답에 다음 Action이나 관계되는 리소스에 대한 HTTP Link를 함께 리턴

   - 페이지 처리의 경우 리턴 시, 전후 페이지에 대한 링크를 제공

   - 연관된 리소스에 대한 디테일한 링크를 표시

 

아직 많이 반영되어 있지는 않음

 

 

# REST는 HTTP를 보다 HTTP답게 만들기 위한 방법론으로 볼 수 있다.

# 철처히 Resource 중심적 설계를 중요시 하고 POST, GET, PUT, DELETE 4가지 메소드를 용도에 맞게 사용한다.

---

오늘은 REST, RESTful에 대해 알아보았습니다. 공부한 내용을 기록한 것이므로 틀린 내용이 있다면 댓글로 남겨주세요. 도움이 되셨다면 좋아요 꾹! 광고 꾹! 해주시면 큰 힘이 됩니다! 좋은 하루 보내세요.^^