REST 란? Restful API 란?

REST 란 ? 

REpresentational Satate Transfer 

 

자원을 표현으로 구분하여 해당 자원의 정보를 주고받는 모든것을 의미한다.

즉, 자원(resource)의 표현(representation)에 의한 정보전달.

 

- 자원 : 해당 소프트웨어가 관리하는 모든 것

ex) 문서, 그림, 데이터, 해당 소프트웨어 자체 등..

 

- 자원의 표현: 자원을 표현하는 지정 방식, 또는 이름

ex) 예를 들어 DB의 학생정보가 자원일 경우, 'students'를 자원의 표현으로 지정한다. 

 

정보전달

데이터가 요청되는 시점에 자원의 정보를 전달한다.

JSON 또는 XML을 통해 데이터를 주고받는 것이 일반적이다.

 

WWW( world wide web) 과 같은 분산 하이퍼미디어 시스템을 위한 SW개발 아키텍처의 한 형식이다.

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

REST는 네트워크 상에서 클라이언트와 서버 간 통신 방식 중 하나이다.

 

REST의 구체적인 개념

HTTP URI (uniform resource identifier )를 통해 자원을 명시하고, 

HTTP 매소드( POST / GET / PUT /DELETE) 를 통해 해당지원에 대한 CRUD operation 을 적용한다.

 

* CRUD operation

CREATE  - 생성 (POST)

READ - 조회 (GET)

UPDATE - 수정 (PUT)

DELETE - 삭제 (DELETE)

HEAD - header 정보조회 (HEAD) 

 

즉, REST는 자원기반의 구조 (ROA : Resource Oriented Architecture) 설계의 중심에 Resource가 있고 HTTP 매소드를 통해 자원을 처리하도록 설계된 아키텍쳐를 의미한다.

웹사이트의 이미지, 텍스트, DB 데이터 등 모든 자원에 고유한 ID 인 HTTP URI를 부여한다.

 

 

REST 구성 요소 

 

1. 자원 (Resource) : URI

모든자원에 고유 ID가 존재하고, 이 자원은 서버에 존재한다.

자원을 구별하는 ID 는 ~/users/:user_id 와 같은 http URI 이다.

클라이언트는 URI를 이용해서 자원을 지정하고, 해당 자원의 정보에 대한 조작을 서버에서 요청한다.

 

Q) URI 과 URL의 차이점?

URL은 Uniform Resource Locator로 인터넷 상 자원의 위치를 의미한다. 

자원의 위치라는 것은 결국 어떤 파일의 위치를 의미한다. 

반면에 URI는 Uniform Resource Identifier로 인터넷 상의 자원을 식별하기 위한 문자열의 구성으로, URI는 URL을 포함한다. 

 

 

2. 행위(Verb) : HTTP 메소드

HTTP 프로토콜의 매소드를 사용한다.

HTTP 프로토콜은 GET / POST / PUT / DELETE 와 같은 메소드를 제공한다.

 

 

3. 표현 (Representation of Resource)

클라이언트가 자원의 정보에 대한 조작을 요청하면 서버는 응답(Representation )을 보낸다.

REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 Representation 으로 나타내어질 수 있다.

일반적으로 JSON , XML 을 통해 데이터를 주고받는다. 

 

 

REST 특징

  1. Uniform Interface(일관된 인터페이스)

Uniform Interface란, Resource(URI)에 대한 요청을 통일되고, 한정적으로 수행하는 아키텍처 스타일을 의미한다.

요청을 하는 Client가 플랫폼(Android, Ios, Jsp 등) 에 무관하며, 특정 언어나 기술에 종속받지 않는 특징을 한다.

 이러한 특징 덕분에 Rest API는 HTTP를 사용하는 모든 플랫폼에서 요청가능하며, Loosely Coupling(느슨한 결함) 형태를 갖는다. 

 

  2. Stateless(무상태성)

서버는 각각의 요청을 별개의 것으로 인식하고 처리해야하며, 이전 요청이 다음 요청에 연관되어서는 안된다. 

Rest API는 세션정보나 쿠키정보를 활용하여 작업을 위한 상태정보를 저장 및 관리하지 않는다. 이러한 무상태성때문에 Rest API는 서비스의 자유도가 높으며, 서버에서 불필요한 정보를 관리하지 않으므로 구현이 단순하다. 

이러한 무상태성은 서버의 처리방식에 일관성을 부여하고, 서버의 부담을 줄여준다.

 

  3. Cacheable(캐시 가능)

Rest API는 결국 HTTP라는 기존의 웹표준을 그대로 사용하기 때문에, 웹의 기존 인프라를 그대로 활용할 수 있다. 

그러므로 Rest API에서도 캐싱 기능을 적용할 수 있는데, HTTP 프로토콜 표준에서 사용하는 Last-Modified Tag 또는 E-Tag를 이용하여 캐싱을 구현할 수 있고, 이것은 대량의 요청을 효울척으로 처리할 수 있도록 한다. 

 

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

Rest API에서 자원을 가지고 있는 쪽이 서버, 자원을 요청하는 쪽이 클라이언트에 해당한다. 서버는 API를 제공하며, 클라이언트는 사용자 인증, Context(세션, 로그인 정보) 등을 직접 관리하는 등 역할을 확실히 구분시킴으로써 서로 간의 의존성을 줄인다. 

 

  5. Self-Descriptiveness(자체 표현)

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

아래와 같은 JSON 형태의 Rest 메세지는 http://localhost:8080/insertBoardInfo 로 게시글의 제목, 내용을 전달하고 있음을 쉽게 알수 있다. 

 

HTTP POST , http://localhost:8080/insertBoardInfo

{ 

"boardVO":{

"title":"제목",

"content":"내용"

	}

}

 

  6. Layered System(계층 구조)

Rest API의 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 등을 위한 계층을 추가하여 구조를 변경할 수 있다. 

또한 Proxy, Gateway와 같은 네트워크 기반의 중간매체를 사용할 수 있게 해준다. 

하지만 클라이언트는 서버와 직접 통신하는지, 중간 서버와 통신하는지 알 수 없다.

 

 

RESTful API란? 

 

API: Application Programming Interface 

 

REST 특징을 지키면서 API를 제공하는 것.

즉, HTTP 통신에서 어떤 자원에 대한 CRUD 요청을 Resource와 Method로 표현하여 특정형태로 전달하는 방식.

 

ex) 예를 들어, 우리는 게시글을 작성하기 위해 http://localhost:8080/bbs/insertBoardInfo라는 URI에 POST방식을 사용하여 JSON형태의 데이터를 전달할 수 있다.

 위와 같이 CRUD 연산에 대한 요청을 할 때, 요청을 위한 Resource(자원, URI)와 이에 대한 Method(행위, POST) 그리고 Representation of Resource(자원의 형태, JSON)을 사용하면 표현이 명확해지므로 이를 REST라 하며, 

이러한 규칙을 지켜서 설계된 API를 Rest API 또는 Restful한 API라고 한다.

 

RESTful API를 사용하는 이유는?

큰 특징으로는 '애플리케이션 분리 및 통합', '다양한 클라이언트의 등장'이다.

애플리케이션의 복잡도가 증가하면서 애플리케이션을 어떻게 분리하고 통합하느냐가 주요 이슈가 되었고, 이에 자바 진영에서는 과거 EJB(Enterprise Java Beans), SOA(Service Oriented Architecture)에 이어 최근에는 MSA(Micro Service Architecture)와 함께 REST가 떠오르고 있는 것이다.

그리고 모바일과 같은 다양한 클라이언트의 등장하면서 최근의 서버 프로그램은 다양한 브라우저와 안드로이폰, 아이폰과 같은 모바일 디바이스에서도 통신을 할 수 있어야 한다.

이러한 멀티 플랫폼에 대한 지원을 위해

Backend 하나로 다양한 Device를 대응할 수 있는 REST의 필요성이 증대되었다.