REST

REST

월드 와이드 웹(World Wide Web a.k.a WWW)과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식으로 자원을 정의하고 자원에 대한 주소를 지정하는 방법 전반에 대한 패턴

RESTful API

REST란, REpresentational State Transfer 의 약자이다. 여기에 ~ful 이라는 형용사형 어미를 붙여 ~한 API 라는 표현으로 사용된다. 즉, REST 의 기본 원칙을 성실히 지킨 서비스 디자인은 ‘RESTful’하다라고 표현할 수 있다. REST가 디자인 패턴이다, 아키텍처다 많은 이야기가 존재하는데, 하나의 아키텍처로 볼 수 있다. 좀 더 정확한 표현으로 말하자면, REST 는Resource Oriented Architecture이다. API 설계의 중심에 자원(Resource)이 있고 HTTP Method 를 통해 자원을 처리하도록 설계하는 것이다.

1. 리소스와행위를 명시적이고 직관적으로 분리한다.
   • 리소스는 URI로 표현되는데 리소스가 가리키는 것은명사로 표현되어야 한다.
   • 행위는HTTP Method로 표현하고,GET(조회),POST(생성),PUT(기존 entity 전체 수정),PATCH(기존 entity 일부 수정),DELETE(삭제)을 분명한 목적으로 사용한다.

REST 6 가지 원칙

• Uniform Interface

RESTful 웹 서비스에서 URI를 사용한다. 자원 자체는 개념적으로 고객에게 반환되는 표현과 분리된다. 예를 들어, 서버는 HTML, XML 또는 JSON으로 데이터베이스로부터 데이터를 전송할 수 있다. 이 중 어떤 것도 서버의 내부 표현이 아니다. 히들 근래에 REST를 이야기 하면, HTTP + JSON을 쉽게 떠올리는데, JSON은 하나의 옵션일뿐, 메시지 포맷을 꼭 JSON으로 적용해야할 필요는 없다. 자바스크립트가 유행하기전에만 해도 XML 형태를 많이 사용했으며, 근래에 들어서 사용의 편리성 때문에 JSON을 많이 사용하고 있다.

크게 4가지 제약조건이 있다.

1. identification of resources
2. manipulation of resources through representation
3. self-descriptive messages
4. hypermedia as the engine of application state

• Stateless

상태가 있다 없다는 의미는 사용자나 클라이언트의 컨택스트를 서버쪽에 유지 하지 않는다는 의미로,쉽게 표현하면 HTTP Session과 같은 컨텍스트 저장소에 상태 정보를 저장하지 않는 형태를 의미한다. 상태 정보를 저장하지 않으면 각 API 서버는 들어오는 요청만을 들어오는 메시지로만 처리하면 되며, 세션과 같은 컨텍스트 정보를 신경쓸 필요가 없기 때문에 구현이 단순해진다.

• Caching

HTTP 프로토콜 표준에서 사용하는 “Last-Modified” 태그나 E-Tag를 이용하면 캐슁을 구현할 수 있다. 아래와 같이 Client가 HTTP GET을 “Last-Modified” 값과 함께 보냈을 때, 컨텐츠가 변화가 없으면 REST 컴포넌트는 304 Not Modified를 리턴하면 Client는 자체 캐쉬에 저장된 값을 사용하게 된다.

이렇게 캐쉬를 사용하게 되면 네트웍 응답시간 뿐만 아니라, REST 컴포넌트가 위치한 서버에 트렌젝션을 발생시키지 않기 때문에, 전체 응답시간과 성능 그리고 서버의 자원 사용률을 비약적으로 향상 시킬 수 있다.

• Client-Server

근래에 들면서 재 정립되고 있는 특징 중의 하나는 REST가 클라이언트 서버 구조라는 것이다. (당연한 것이겠지만). REST 서버는 API를 제공하고, 제공된 API를 이용해서 비즈니스 로직 처리 및 저장을 책임진다. 클라이언트의 경우 사용자 인증이나 컨택스트(세션,로그인 정보)등을 직접 관리하고 책임 지는 구조로 역할이 나뉘어 지고 있다. 이렇게 역할이 각각 확실하게 구분되면서, 개발 관점에서 클라이언트와 서버에서 개발해야 할 내용들이 명확하게 되고 서로의 개발에 있어서 의존성이 줄어들게 된다.

• Hierarchical system

계층형 아키텍쳐 구조 역시 근래에 들어서 주목받기 시작하는 구조인데, 클라이언트 입장에서는 REST API 서버만 호출한다. 그러나 서버는 다중 계층으로 구성될 수 있다. 순수 비즈니스 로직을 수행하는 API 서버와 그 앞단에 사용자 인증 (Authentication), 암호화 (SSL), 로드밸런싱등을 하는 계층을 추가해서 구조상의 유연성을 둘 수 있는데, 이는 근래에 들어서 앞에서 언급한 마이크로 서비스 아키텍쳐의 api gateway나, 간단한 기능의 경우에는 HA Proxy나 Apache와 같은 Reverse Proxy를 이용해서 구현하는 경우가 많다.

• Code on demand

Code on demand 스크립트나 플러그인 같은 실행 가능한 프로그램을 일시적으로 클라이언트에 전송하여, 클라이언트가 실행할 수 있도록 한다. 주문형 코드는 웹 서버와 클라이언트 사이에 기술적 결합을 만들어내기도 하는데, 클라이언트는 필요할 때마다 서버에서 내려받은 실행 코드를 이해해야 하기 때문이다. 이러한 이유로 주문형 코드는 웹의 구조적 스타일에서 유일한 선택사항이다. 주문형 코드 제약사항의 예로 자바 애플릿, 자바스크립트, 플래시 같은 웹 브라우저 기반의 기술들이 있다.

가장 쉬운 예로는 크롬 개발자 도구 Console에서 eval('console.log("Test")'); 명령어를 치는것이다.

REST Method

• GET

요청받은 URI의 정보를 검색하여 응답한다.

• HEAD

GET방식과 동일하지만, 응답에 BODY가 없고 응답코드와 HEAD만 응답한다. 웹서버 정보확인, 헬스체크, 버젼확인, 최종 수정일자 확인등의 용도로 사용된다.

• POST

요청된 자원을 생성(CREATE)한다. 새로 작성된 리소스인 경우 HTTP헤더 항목 Location : URI주소를 포함하여 응답.

• PUT

요청된 자원을 수정(UPDATE)한다. 내용 갱신을 위주로 Location : URI를 보내지 않아도 된다. 클라이언트측은 요청된 URI를 그대로 사용하는 것으로 간주함.

• DELETE

요청된 자원을 삭제할 것을 요청함. (안전성 문제로 대부분의 서버에서 비활성)

• CONNECT

동적으로 터널 모드를 교환, 프락시 기능을 요청시 사용.

• OPTIONS

웹서버에서 지원되는 메소드의 종류를 확인할 경우 사용

• TRACE

원격지 서버에 루프백 메시지 호출하기 위해 테스트용으로 사용.

• PATCH

PUT과 유사하게 요청된 자원을 수정(UPDATE)할 때 사용한다. PUT의 경우 자원 전체를 갱신하는 의미지만, PATCH는 해당자원의 일부를 교체하는 의미로 사용.

장점

• Open API 를 제공하기 쉽다
• 멀티플랫폼 지원 및 연동이 용이하다.
• 원하는 타입으로 데이터를 주고 받을 수 있다.
• 기존 웹 인프라(HTTP)를 그대로 사용할 수 있다.

단점

• 사용할 수 있는 메소드가 4 가지 밖에 없다.
• 분산환경에는 부적합하다.
• HTTP 통신 모델에 대해서만 지원한다.

URI vs URL vs URN

URI (통합 자원 식별자, Uniform Resource Identifier)

인터넷에 있는 자원을 나타내는 유일한 주소이다. URI의 존재는 인터넷에서 요구되는 기본조건으로서 인터넷 프로토콜에 항상 붙어 다닌다. URI의 하위개념으로 URL, URN이 있다.

문법

schema:[//[user[:password]@]host[:port]][/path][?query][#fragment]

URL (파일 식별자, Uniform Resource Locator)

네트워크 상에서 자원이 어디 있는지를 알려주기 위한 규약이다. 즉, 컴퓨터 네트워크와 검색 메커니즘에서의 위치를 지정하는, 웹 리소스에 대한 참조이다. 그래서 해당 리소스에 대한 위치가 계속해서 변할 수 있다. 흔히 웹 사이트 주소로 알고 있지만, URL은 웹 사이트 주소뿐만 아니라 컴퓨터 네트워크상의 자원을 모두 나타낼 수 있다. 그 주소에 접속하려면 해당 URL에 맞는 프로토콜을 알아야 하고, 그와 동일한 프로토콜로 접속해야 한다.

Example

• http://example.com/mypage.html
• ftp://example.com/download.zip
• mailto:user@example.com
• file:///home/user/file.txt
• tel:1-888-555-5555
• http://example.com/resource?foo=bar#fragment

URN — Uniform Resource Name

URN은 영속적이고, 위치에 독립적인 자원을 위한 지시자로 사용하기 위해 RFC 2141문서에서 정의되었다.

Example

• urn:isbn:0451450523 to identify a book by its ISBN number.
• urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66a globally unique identifier

즉, 사람으로 비유를 하면 URI는 ‘김철수’이며, URL은 ‘김철수가 사는 주소’다 이 위치는 계속해서 변할수 있다. 하지만 URN은 ‘김철수의 주민등록번호’라고 생각하면된다. 한번 정해진 URN은 바뀌지 않기 때문이다.

MIME

MIME 타입이란 클라이언트에게 전송된 문서의 다양성을알려주기 위한 메커니즘입니다:웹에서 파일의 확장자는 별 의미가 없습니다. 그러므로,각 문서와 함께 올바른MIME 타입을 전송하도록,서버가 정확히 설정하는 것이중요합니다.브라우저들은 리소스를 내려받았을 때해야 할 기본 동작이 무엇인지를 결정하기 위해 대게 MIME 타입을 사용합니다. 이와 관련해서 가장 주용한 것은 헤더는 또한 보내지는 자원의 content 타입이 포함되는 것이다. 이것은 Content-Type 헤더에 의해 지정되는데, 이 값은 표준 MIME-Type의 하나이다.

Example

Content-Type: text/css Content-Type: text/xml

Text

text/plain, text/html, text/css, text/javascript

Image

image/gif, image/png, image/jpeg, image/bmp

Video

vidoe/webm, video/ogg

Proxy

프록시 서버는 클라이언트가 자신을 통해서 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해 주는 컴퓨터 시스템이나 응용 프로그램을 가리킨다. 서버와 클라이언트 사이에 중계기로서 대리로 통신을 수행하는 것을 가리켜 ‘프록시’, 그 중계 기능을 하는 것을 프록시 서버라고 부른다.