본문으로 바로가기

REST 제대로 알고 프로젝트에 적용하기

category Project/gist 2019. 4. 20. 09:00

REST란? (Representational State Transfer)

리소스들에 대한 행위를 HTTP Method로 표현하는 것을 말한다. 엄격한 의미로 'REST'는  '네트워크 아키텍처' 원리의 모음이다. '네트워크 아키텍처' 원리란 자원을 정의하고 자원에 대한 주소를 지정하는 방법 전반을 일컫는다. RWS (RESTful Web Service) 라고 하는 REST  아키텍처 스타일을 따르는 웹서비스는 인터넷상의 컴퓨터 시스템 간의 상호 운용성을 제공한다. RESTful 웹서비스는 요청 시스템이 균일하고 미리 정의된무상태 연산 세트(GET, POST, PUT, DELETE) 를 사용하여 웹 리소스의 텍스트 표현에 엑세스하고 조작할 수 있게 해준다.

REST의 구성 요소

자원 (Resource) 

  • 수행 대상이 되는 리소스를 말한다.

  • 초기에는 URL로 식별 가능한 문서나 파일을 리소스라고 불렀으나 그 의미가 점점 일반화되었다.

  • 이제는 리소스는 JSON, XML 문서가 될 수도 있고, jpg 파일 같은 이미지, MP3 같은 비디오가 될 수도 있다.

행위 (Verb) 

  • REST API 에서는 리소스에 대한 행위가 일관되게 정의된다.

  • REST API에서 사용되는 메소드는 HTTP Method로 GET, POST, PUT, DELETE 등이 있다.

  • 이들은 각각 CRUD에 다음과 같이 매핑될 수 있다.

HTTP Method

(CRUD) :  역할 

POST

(create) :  해당 URI를 요청하면 자원을 생성한다.

GET

(read) : 해당 자원을 조회한다. 

PUT

(update/replace) : 해당 자원을 바꾼다. 만약 리소스가 존재하지 않을 경우에는 request body에 표현한 자원으로 새로운 자원을 생성할 수도 있다.

PATCH

(update/modify) : 해당 자원을 업데이트한다. 존재하지 않을 경우 request body에 있는 지시 사항(instruction)에 따라 자원을 생성할 수도 있다.

DELETE

(delete) : 자원을 삭제한다.

표현 (Prepresentations) 

  • 정보의 자원은 URI (Uniform REsource Identifier)로 표현된다.

  • 자원에 대한 행위(Verb)는 위에서 설명한 HTTP Method로 표현된다.

REST 아키텍처에 적용되는 6가지 제한 조건 

RESTful 시스템에는 6가지의 가이드가 존재한다. (이 부분은 wiki 문서를 위주로 참고로 하여 작성되었다)

RESTful의 제약 조건에 따라서 서버가 클라이언트의 요청을 처리하고 응답하는 방법을 제약함으로써 개발자는 확장성, 단순성, 수정 간으성, 가시성, 이식성 및 신뢰성과 같은 비 기능적인 특성들을 얻는다. REST에서 말하는 아래의 6가지 가이드를 위반할 경우에는 RESTful이라고 간주 할 수 없다. 

Client-server architecture

REST 아키텍처를 적용한 서비스에서는 서버와 클라이언트의 역할을 명확히 구분해야 한다. 이로써 REST 서버는 데이터 저장소로부터 필요한 자원을 어떻게 하면 잘 관리(조회, 추가, 삭제, 변경)할 수 있는지에 대해서만 집중하면 된다. 클라이언트에서는 사용자 인증이나 컨텍스트(세션, 로그인 정보) 등을 직접 관리한다. 이로써 각각 개발해야 하는 부분이 명확해지고 서로간의 의존성이 줄어들게 된다. 이러한 점은 오히려 서버와 클라이언트 각각의 부분에서 발전이 가능해진다.

(추측하자면) 예를 들어, 서버 측에서는 클라이언트 측에서 발생하는 문제들에 대한 고민 없이 어떤 대규모 요청이 들어오더라도 요청 상황에 대한 올바른 결과물을 돌려주는데에만 개발을 집중할 수 있고 클라이언트 측에서도 서버 측에서 발생할 문제들을 고민할 필요가 없이 항상 올바른 결과물을 내려줄거란 확신이 있으므로 클라이언트 부분을 발전시키는데에만 집중할 수 있다.

Statelessness

서버에는 클라이언트의 컨텍스트를 저장하지 않는다. 따라서 모든 클라이언트의 각 요청에는 처리하는데 필요한 모든 정보가 포함되어 있으며 세션 상태는 클라이언트 쪽에 보관된다. 클라이언트의 요청에 담아 전달된 세션 상태는 서버와 같이 데이터베이스와 같은 다른 서비스로 전송되어 일정 기간동안 지속상태를 유지하고 인증하는데 사용된다. 

Cacheability

RESTful Web Service에서는 HTTP라는 기존 웹표준을 그대로 사용하기 때문에 웹에서 사용하는 기존 인프라를 그대로 활용할 수 있다. 따라서 REST 아키텍처에서는 HTTP가 가진 캐싱 기능을 활용할 수 있다. HTTP 프로토콜 표준에서 사용하는 Last-Modified 태그나 E-Tag를 이용하면 캐싱 구현이 가능하다. 부실한 응답이 있을 경우에는 캐싱할지에 대한 여부를 잘 정의해야 한다. 잘 관리된 캐싱은 일부 클라이언트 - 서버의 요청에 대해서 부분적으로 또는 전체 부분을 대체할 수 있으므로 성능과 확장성을 더욱 향상 시킬 수 있다. 

Layered system

클라이언트는 단순히 REST 서버에 요청을 보낼 뿐, 직접 최종 서버에 요청을 한것인지 아니면 중간 중개자에게 요청을 한지 알 수 없다. 단순히 원하는 결과를 받았는지 여부만이 중요할 뿐이다. 그 말은 즉, REST 서버는 다중 계층으로 구성될 수 있다.  보안, 로드 밸런싱, 암호화 계층을 추가하여 구조성의 유연성을 둘 수 있고 PROXY, 게이트 웨이와 같은 네트워크 기반의 중간 매체를 사용할 수도 있다. 

Code on demand (potional)

서버는 클라이언트가 실행시킬 수 있는 로직( ex) Javascript와 같은 클라이언트 측 스크립트)을 전송하여 클라이언트의 기능을 일시적으로 확장하거나 사용자 정의를 할 수 있다.

Uniform interface

아래와 같은 제약 조건에 따라서 URI를 결정함으로써 아키텍처를 단순화하고 분리하여 각 부분을 개별적으로 발전시킬 수 있다. 

REST 인터페이스의 원칙에 대한 가이드

  • Resource identification in requests

    • 요청 부분에서 개별 자원에 대한 식별을 할 수 있어야 한다. 

    • 웹 기반의 REST 시스템에서는 URI를 예를 들 수 있다. 

    • 자원 그 자체는 클라이언트가 받는 문서와는 개념적으로 분리되어 있다.

    • 예를 들어, 서버는 데이터베이스 내부의 자료를 직접 전송하는 대신, DB의 레코드를 HTML, XML이나 JSON 등의 형태로 전송한다.

  • Resource manipulation through representations

    • 메시지를 통한 자원을 조작한다.

    • 클라이언트의 요청에 어떤 자원에 대한 적절한 표현과 작업을 수행하기 위한 메타데이터를 충분히 갖추고 있다면, 이것은 서버 상에서 해당 자원을 변경, 삭제할 수 있는 충분한 정보를 가지고 있는 것이다.

  • Self-descriptive messgaes

    • 각 메시지는 자신을 어떻게 처리해야 하는지에 대한 충분한 정보를 포함해야 한다. 예를 들어, MIME type과 같은 인터넷 미디어 타입을 전달한다면, 그 메시지에는 어떤 parser를 사용해야 하는지에 대한 정보도 포함해야 한다. 미디어 타입만 가지고도 클라이언트는 어떻게 그 내용을 처리해야 할지에 대해 알 수 있어야 한다. 메시지를 이해하기 위해서 그 내용까지 살펴봐야 한다면, 그 메시지는 자기 서술적(Self-descriptive) 하지 않다. 예를 들어, 단순히 'application/xml'이라는 미디어 타입은, 실제 내용을 다운로드 하지 않으면 그 메시지만으로는 무엇을 해야 할지에 대해서 충분히 알려준 것이 아니다.
  • Hypermedia as the engine of application state

    • 애플리케이션의 상태에 대한 엔진으로서의 하이퍼미디어
    • 만약에 클라이언트가 관련된 리소스에 접근하기를 원한다면, 리턴되는 지시자에서 구별될 수 있어야 한다. 충분한 콘텍스트 속에서의 URI를 제공해주는 하이퍼텍스트 링크의 예를 들 수 있다.

REST의 주요 목표

  • 구성 요소 상호 작용의 규모 확장성

  • 인터페이스의 범용성

  • 구성 요소의 독립적인 배포

  • 중간적 구성요소를 이용해 등답 지연 감소, 보안을 강화, 레거시 시스템을 인캡슐레이션 하기

REST API는 무엇인가

위에서 설명한 REST 구조 제한 조건을 준수한 웹 서비스 API를 RESTful API라고 한다. 위에 표로 명시된 HTTP methods가 전형적으로 RESTful API에서 사용되는 메소드들이다. 

참고 링크

REST API 제대로 알고 사용하기 : https://meetup.toast.com/posts/92

REST(Representational state transfer) : https://en.wikipedia.org/wiki/Representational_state_transfer