4차 REST 아키텍처 소개(2)

REST 원리 및 원칙에 대해서 알아 보자.
Resource와 Representation을 구분할 수 있다.

REST란 Representational State Transfer의 약자이며 데이터의 Representation 전송해 주는 방식이다.

REST란 무엇인가?

• HTTP를 보다 HTTP 답게 만들기 위한 방법론으로 볼 수 있음 (일반적으로 아키텍처 보단 방법론으로 본다.)
• 철저히 Resource 중심적 설계를 중요시하고
  • Create - POST
  • Read - GET
  • Update - PUT
  • Delete - DELETE와 같이 HTTP 4가지 메소드를 용도에 맞게 사용

REST 원리 및 원칙(제약조건)
확장성 있는 웹 서비스를 위한 소프트웨어 아키텍처 적인 접근

1. Client-Server

   • View와 Data를 분리
   • Portability(이동성)를 향상
   • REST 서버는 Resource를 관리하는 API를 제공
     • 클라이언트는 사용자 인증이나 Context(Session, Login 정보) 직접관리
     • 서버는 UI나 User State에 상관없이 Server 기능에 집중(단순화, 확장성)

2. Stateless

   • 요청 자체가 같다면 응답도 같아야 한다. input 이 같으면 항상 output이 같아야 한다.
     (퓨어펑션 함수형 프로그램 핵심적인 컨셉)
   • 클라이언트의 상태를 서버에 저장하지 않음(확장성)
   • 세션정보와 같은 context를 저장할 필요가 없음
   • 클라이언트는 자신을 구분하기 위해 서버에게 충분한 정보를 전달해야 함
     • API Key 또는 Token

3. Cacheable

   • HTTP 프로토콜의 Caching 기능을 적용할 수 있음
     • 웹 서비스의 60~80%가 GET 방식의 요청
     • 구현은 HTTP 프로토콜 표준인 "Last-Modified" 태그나 E-Tag를 이용

4. Layeredsystem

5. Code on demand(optional)

   • 서버는 실행 가능한 코드를 클라이언트에게 전송
     • 클라이언트의 기능을 일시적으로 확장하거나 커스터마이징 가능
     • Java Applet, JavaScript가 대표적 예
   • 최근에는 사용안하는 추세

6. Uniform interface

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

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

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

     1. Resource Identifier -> URI

        • Resource는 서비스나 정보를 제공하는 모든 것들이 될 수 있음
        • 주문, 송장, DB의 레코드, 검색 결과 등
        • 웹 상에서 주소를 통해 접근 될 수 있음
        • 즉, 리소스는 URI를 반드시 가져야 함
        • URI 정의는 동사형이 아닌 명사형으로 정의하도록 권장됨

     2. Resource Representations

        • Resource 는 Unique ID로 하나 이상의 URI뿐만 아니라,
          다양한 방법으로 설명(대표)되는 Representation을 가질 수 있음
        • Representation 에 대한 접근을 위한 URL을 가지고
        • HTTP 4가지 메서드(POST/GET/PUT/DELETE)를 통해 CRUD 할 수 있음
        • GET 메서드 정의
          • Target resource에 대한 현재의 선택된 representation 하나를 반환함
          • 리소스는 HTTP 요청의 대상이지만, 리소스의 개념을 제한하지 않음
        • Representation 이란?
          • 어떤 리소스의 특정 시점의 상태를 반영하고 있는 정보
          • 다음 두 가지로 구성됨
            • Representation data
            • Representation metadata

     3. Self-Descriptive Message

        • REST는 Stateless 라서
        • 클라이언트 - 서버 간 충분한 설명적인 메시지가 필요
          • HTTP 메서드
          • HTTP 상태코드
          • HTTP 헤더

     4. HATEOAS (Hypermedia As The Engine Of Application State)

        • HATEOAS 메시지를 보내는 것은 어플리케이션의 상태를 변화시킴
        • HTTP 응답에 다음 Action이나 관계되는 리소스에 대한 HTTP Link를 함께 리턴
          • 페이지 처리의 경우 리턴 시, 전후 페이지에 대한 링크를 제공
          • 연관된 리소스에 대한 디테일한 링크를 표시
        • 현재 대부분 적용하고 있지 않음.

RESTful 하다 라는 의미란?
API 서비스를 설계하고 운영할 때 Restful 하다는 의미는 다음을 최소한 포함한다.
1. API의 Endpoint가 오직 하나이다.
2. 요청을 GET, POST, PUT, DELETE를 다향하게 사용한다.
3. 요청과 응답에 대한 메타데이터는 HTTP 프로토콜 방식을 사용한다.
4. URL에 동사(verb)를 포함하지 않는다.