REST

  • REpresentational State Transfer, Roy Fielding
  • REpresentational State Transfer → 표현 상태 전송
  • 월드 와이드 웹(World Wide Web a.k.a WWW)과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식으로 자원을 정의하고 자원에 대한 주소를 지정하는 방법 전반에 대한 패턴이다.
  • REST가 디자인 패턴이다, 아키텍처다 많은 이야기가 존재하는데, 하나의 아키텍처로 볼 수 있다. 좀 더 정확한 표현으로 말하자면, REST 는 Resource Oriented Architecture 이다. API 설계의 중심에 자원(Resource)이 있고 HTTP Method 를 통해 자원을 처리하도록 설계하는 것이다. (기술 면접 준비 Github)
  • REST API(RESTful API, 레스트풀 API)란 REST 아키텍처의 제약 조건을 준수하는 애플리케이션 프로그래밍 인터페이스를 뜻합니다. REST는 Representational State Transfer의 줄임말입니다. (RedHat)

Representation

  • HTTP에서 "Representation"은 과거, 현재, 또는 원하는 상태를 반영하기 위해 리소스에 프로토콜로 쉽게 전달할 수 있는 형식이며, representation metadata 집합과 경계가 없는 representation data 스트림으로 구성된다. → RFC7231
  • 표현, 표시, 서술, 묘사, 상징
  • What does Representational State mean in REST?
  • 흔히 여러 블로그에서 표현으로 분류되는 것 같다.

Representation metadata

  • Representation 헤더 필드 이름은 representation에 대한 메타 데이터를 제공한다.
  • 메시지에 payload 바디가 포함되었을 때 representation 헤더 필드는 payload 바디에 포함된 representation data를 해석하는 방법을 설명한다.
  • 헤더 필드 이름
    • Content-Type : 미디어 타입 (ex. text/html)
    • Content-Encoding : (ex. gzip)
    • Content-Language : 언어 (ex. ko, en)
    • Content-Location : URI

Resource

  • HTTP 요청의 대상을 "Resource"라고 한다. Resource에는 특성의 제한이 없다. Resource와 상호작용하는데 사용하는 인터페이스를 정의한다.
  • 이것을 URI로 식별한다. → RFC7230
  • 흔히 여러 블로그에서 자원으로 분류되는 것 같다.

Request methods

  • HTTP는 원래 분산 객체 시스템에 대한 인터페이스로 사용 할 수 있도록 설계되었다. Request method는 식별되는 객체에 정의된 method를 호출하면 대상 resource에 method를 적용하는 것으로 구상되있다.
  • 정의된 표준 method는 모든 resource에 적용될 때 동일한 의미를 가져야 하지만, 각 recource는 해당 의미가 구현 또는 허용되는지 자체적으로 결정한다. → RFC7231
  • 일반적으로 GET, POST, PUT, DELET를 따라 CRUD라고 통칭한다.
  • 흔히 여러 블로그에서 행위로 분류되는 것 같다.

SOAP와 차이점

  • 주로 RESTful과 비교할때 많이 등장하는 전송 프로토콜이다.
  • Simple Object Access Protocol : - RESTful API와 주로 비교되는 프로토콜. 트랜잭션의 기본 속성인 ACID를 스팩으로 갖고 있다 HTTP뿐만 아니라 SMTP, TCP등 다영한 계층을 처리 할수 있다는 장점은 있으나 기능이 많은 만큼 오버헤드도 크다. 요청에 XML로 반환한다.
  • 그에 비해 REST는 HTTP로 통신하긴 하지만 SOAP보다 훨씬 유연하다. 요청에 대해 XML뿐만 아니라 HTTP, 텍스트, JSON등 다양한 포맷으로 반환할 수 있고 6가지 가이드 라인에 따라 보다 경량화된 아키텍쳐라고 볼 수 있다.

Stateful, Stateless

  • 상태란 해당 시점의 상황을 말한다.
  • Stateful은 이전 트랜잭션의 영향을 받으며 컨텍스트에 따라 수행된다. 그러므로 요청을 처리할 때 마다 같은 세션을 이용한다. 컨텍스트 내역이 저장되기 때문에 작업이 중단 되어도 다시 시작할 수 있다. 여기서는 SOAP가 대표적이라고 볼 수 있겠다.
  • Stateless는 트랜잭션에서 격리되는 것을 간주한다. 과거 상태가 저장되기 않기 때문에 모든 트랜잭션은 처음부터 시작된다. (RedHat)
  • RESTful에서 Stateless하다는 것은 서버가 클라이언트의 어떤 상태도 저장하지 않는다는 뜻이다. 따라서 클라이언트가 요청을 보낼때는 토큰 또는 키를 요청에 포함시켜 전송한다. 만약 stateful 하다면 서버가 클라이언트의 세션을 저장해야 하는데 이러면 세션 클러스터가 필요하다. 반면 클라이언트가 매번 인증정보를 담아 서버에 보낸다면 세션 상관없이 어떤 서버나 요청을 처리할 수 있는 것이다. → RESTful, Stateless, HATEOAS 그리고 Passport

정제된 글이 있으면 좋았을텐데 검색으로 나타나는 여러 글을 읽어봐도 너무 자의적인 해석이나 문장력 떨어지는 글 밖에 없어서 다시 정리해봤다. 계속 추가할 수 있으면 좋겠다.

Comments