개념

What is REST?

  • Representational State Transfer
  • 자원을 이름으로 구분하여 해당 자원의 상태(정보)를 주고받는 모든 것
  • 자원의 표현에 의한 상태 전달
    • 자원의 표현
      • 자원: 해당 소프트웨어가 관리하는 모든 것
      • 자원의 표현: 그 자언을 표현하기 위한 이름
      • e.g. DB의 학생 정보가 자원 → ‘students’를 자원의 표현으로 정함
    • 상태(정보) 전달
      • 데이터가 요청되어지는 시점에 자원의 상태(정보)를 전달
      • JSON 혹은 XML을 통해 데이터를 주고 받는 것이 일반적
  • 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용 → 웹의 장점을 최대한 활용할 수 있는 아키텍쳐 스타일
  • NW상에서 Client와 Server 사이의 통신 방식 중 하나
  • HTTP URI를 통해 자원(Resource)을 명시하고
    • URI
      • Uniform Resource Identifier
      • 인터넷 자원을 나타내는 고유 식별자
      • 인터넷에 있는 자료의 ID
      • URI는 유일해야 함
      • URL
        • Uniformed Resource Locator
        • 프로토콜 포함
        • 해당 자원의 위치, Path 의미
        • 일반적으로 사이트 도메인을 자주 의미
        • 웹 상 뿐만 아니라 컴퓨터 네트워크 상의 자원은 모두 나타낼 수 있음
      • URN
        • Uniformed Resource Name
        • 프로토콜 포함 X
        • 해당 자원의 이름을 의미
        • 독립적인 자원 지시자
        • Page 이후 부분까지 포함
  • HTTP Method(POST, GET, PUT, DELETE)를 통해
  • 해당 자원에 대한 CRUD Operation을 적용하는 것
    • CRUD Operation
      • 대부분의 컴퓨터 소프트웨어가 가지는 기본적인 데이터 처리 기능
      • Create(생성)
        • POST(데이터 생성)
      • Read(읽기)
        • GET(데이터 조회)
      • Update(갱신)
        • PUT, PATCH(데이터 수정)
      • Delete(삭제)
        • DELETE(데이터 삭제)
      • HEAD
        • HEAD(header 정보 조회)

⇒ ROA(Resource Oriented Architecture; 자원 기반의 구조) 설계의 중심에 Resource가 있고 HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍처

  • 웹 사이트의 이미지, 텍스트, DB 내용 등의 모든 자원에 고유한 ID인 HTTP URI를 부여

REST 구성 요소

Resource(자원)

  • HTTP URI

Verb(자원에 대한 행위)

  • HTTP Method

Representation(자원에 대한 행위의 내용)

  • HTTP Message Pay Load

REST의 특징

Server-Client

  • Client: 유저와 관련된 처리
  • Server: REST API 제공
  • 각각의 역할이 확실하게 구분 + 일괄적인 인터페이스로 분리되어 작동
  • REST Server: API 제공 + 비지니스 로직 처리 및 저장 책임
  • Client
    • 사용자 인증 or context(세션, 로그인 정보) 등을 직접 관리하고 책임
  • 서로 의존성 감소

Stateless(무상태성)

  • HTTP의 특성을 이용 → 무상태성을 갖음
  • 서버에서 어떤 작업을 하기 위해 상태정보 기억 필요 X
  • 들어온 요청에 대해 처리만 해주면 됨 → 구현이 쉽고 단순
    • What is Stateless(무상태성)
      • 서버가 클라이언트의 상태를 보존하지 않음
      • Good: 서버 확장성에 용이
      • Bad: 클라이언트가 추가 데이터를 전송해야 함
      • Limit
        • 로그인이 필요 X 단순한 서비스 소개 화면 → 무상태 설계 O
        • 로그인 필요 O → 유저의 상태 유지 ⇒ 브라우저 쿠키, 서버 세션, 토큰 등을 이용해 상태 유지 → 최소한만 사용
      • Stateful(상태 유지)
        • Client 요청 1에 대한 상태를 해당 요청을 받은 서버 A가 기억
        • 항상 같은 서버 A가 유지지되어야 함
        • IF) 서버A 장애 → 유지되던 상태 정보 X → 처음부터 다시 요청
        • IF 무상태 프로토콜?) Client 요청 1 w/ 데이터 → 아무 서버나 호출 O ⇒ 응답 서버 쉽게 변경 O → 무한한 서버 증설 가능

Cacheable(캐시 처리 가능)

  • HTTP 기존 웹표준 사용 → 기본 웹에서 사용하는 인프라 그대로 사용 가능
  • 대량의 요청을 효율적으로 처리하기 위해 캐시 요구
  • 캐시 사용 → 응답시간 빠름 + REST Server 트랜잭션 발생 X ⇒ 전체 응답시간, 성능, 서버의 자원 이용률 향상 가능

Self-Descriptiveness(자체 표현 구조)

  • JSON을 이용한 메세지 포맷 이용 → 직관적 이해 O
  • REST API 메세지만으로 그 요청이 어던 행위를 하는지 알 수 있음

Layered System(계층화)

  • Client와 Server 분리 → 중간에 프록시 서버, 암호화 계층 등 중간매체를 사용할 수 있음 ⇒ 자유도 높음

Uniform Interface(인터페이스 일관성)

  • HTTP 표준에만 따른다면 모든 플랫폼에서 사용 O
  • URI로 지정한 리소스에 대한 조작을 가능하게 하는 아키텍쳐 스타일
  • URI로 지정한 Resource에 대한 조작을 통일되고 한정적인 인터페이스로 수행
  • 특정 언어나 기술에 종속 X

Rule

중심 규칙

  • URI는 정보의 자원을 표현해야 함
  • 자원에 대한 행위는 HTTP Method (GET, POST, PUT, DELETE 등)으로 표현

세부 규칙

  • 슬래시 구분자(/)는 계층 관계를 나타내는데 사용
  • URI 마지막 문자로 슬래시(/)를 포함하지 않음
    • UIR에 포함되는 모든 글자는 리소스의 유일한 식별자로 사용되어야 함
    • URI가 다름 == 리소스가 다름 ⇒ 리소스 다름 → URI도 달라져야 함
  • 하이픈(-)은 URI 가독성을 높이는데 사용
  • 밑줄(_)은 URI에 사용하지 않음
  • URI 경로에는 소문자가 적합
    • URI 경로에 대문자 사용은 피하도록 함
  • 파일확장자는 URI에 포함하지 않음
    • REST API에서는 메세지 바디 내용의 포맷을 나타내기 위한 파일 확장자를 URI 안에 포함시키지 않음
    • 대신 Accept Header를 사용
      • e.g. GET: http://restapi.exam.com/orders/2/Accept: image/jpg
  • 리소시 간에 연관 관계가 있는 경우
    • /리소스명/리소스ID/관계가 있는 다른 리소스 명
    • e.g. GET: /users/2/orders (일반적으로 소유의 관계를 표현할 때 사용) https://hackernoon.com/build-restful-api-in-go-and-mongodb-5e7f2ec4be94 https://hackernoon.com/build-restful-api-in-go-and-mongodb-5e7f2ec4be94

REST 설계 목표

상호연동성 확보

  • 상호연동성
    • “서로 상이한 컴포넌트”들을 쉽게 연결할 수 있는 성질
  • 두 개 이상의 컴포넌트들을 결합 → 작업을 더 효율적으로 수행하도록 함
  • REST = HTTP + URI 기반
    • HTTP, URI → 표준, 직관적이고 사용 간단, 어디서든 동일 작동 보장

범용 인터페이스

  • REST 모델을 위한 HTTP와 URI는 표준 → 어디서든지 사용가능한 범용 인터페이스 제공
  • 개발자는 비지니스 로직만 고민하면 됨~

각 컴포넌트들의 독립적인 배포

  • 다른 컴포넌트들과 독립적으로 개발할 수 있음
  • 규격에 맞추어 개발 0> 다른 컴포넌트가 추가되어도 연동 걱정 X

컴포넌트 중계 역할

  • 클라이언트는 엔드 서버에 직접 연결할 필요 X
    • WHY?
      • REST 서버가 클라이언트와 엔드 서버 중간에서의 중계역할
  • 로드 밸런싱, 공유 메모리 등을 이용해서 확장성/성능 향상 O
    • 로드밸런싱
      • 부하 분산
      • 컴퓨터 NW 기술의 일종
      • 둘 or 셋 이상의 중앙처리장치 or 저장장치와 같은 컴퓨터 자원들에게 작업을 나누어 주는 것
  • 보안 정책 적용 용이
  • 지연 감소, 보안강화, 레거시 시스템을 인캡슐레이션 하는 중간 컴포넌트로의 역할
    • 인캡슐레이션
      • 데이터에 헤더가 추가되는 과정
      • OS Lv7 → Lv1로 내려가는 과정
      • PC에서 다른 PC로 데이터를 전송할 때 데이터를 패키지화하는 과정

REST의 장단점

장점

  • HTTP 프로토콜 인프라 그대로 사용 → REST API 사용을 위한 별도의 인프라 구축 필요 X
  • HTTP 프로토콜의 표준을 최대한 활용 → 추가적 장점을 함께 가져갈 수 있게 해 줌
  • HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용 가능
  • Hypermedia API의 기본을 충실히 지키며 범용성 보장
  • REST API 메세지가 의도하는 바를 명확하게 나타냄 → 의도하는 바를 쉽게 파악할 수 있음
  • 여러가지 서비스 디자인에서 생길 수 있는 문제를 최소화
  • 서버와 클라이언트 역할을 명확히 분리

단점

  • 표준이 자체가 존재하지 안아 정의가 필요
  • HTTP Method 형태가 제한적
  • 브라우저를 통해 테스트할 일이 많은 서비스 → URL보다 Header 정보의 값을 처리해야 함 → 전문성 요구
  • 구형 브라우저에서 호환이 되지 않아 지원해주지 못하는 동작이 많음(explorer)
  • HTTP에 상당희 의존적
    • REST는 설계 원리 → HTTP와 상관없이 다른 프롴토콜에서 구현 O BUT! 자연스러운 개발 HARD!
    • REST를 사용하는 이유: 대부분의 서비스가 웹으로 통합되는 상황

What is REST API?

What is API?

Untitled

  • Application Programming Interface
  • 응용 프로그램에서 사용할 수 있도록 OS나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스
  • REST의 특징을 기반으로 서비스 API를 구현한 것
  • 최근 OpenAPI, 마이크로 서비스 등을 제공하는 기업 대부분은 REST API 제공

REST API 특징

  • 각 요청이 어떤 동작이나 정보를 위한 것인지를 그 요청의 모습 자체로 추론이 가능

REST API 디자인 가이드

  • URI 는 정보의 자원을 표현해야 함
  • 자원에 대한 행위는 HTTP Method(GET, POST, PUT, PATCH, DELETE)로 표현
    • Method는 URI에 포함 X

What is RESTful API?

What is RESTful?

  • HTTP와 URI 기반으로 자원에 접근할 수 있도록 제공하는 애플리케이션 개발 인터페이스
  • HTTP 메소드 + URI만으로 인테넛에 자료를 CRUD 할 수 있음
  • REST API를 제공하는 웹 서비스 → RESTful 하다고 할 수 있음
  • RESTful
    • REST를 REST답게 쓰기 위한 방법
    • 누군가 공식적으로 발표한 것은 아님

RESTful API 개발 원칙

  1. 자원을 식별할 수 있어야 함
    • URL(Uniform Resource Locator)만으로 내가 어떤 자원을 제어하려고 하는지 알 수 있어야 함
    • 자원을 제어하기 위해, 자원의 위치는 물론 자원의 종류까지 알 수 있어야 함
    • Server가 제공하는 정보는 JSON이나 XML 형태로 HTTP body에 포함되어 전송 시킴
  2. 행위는 명시적이어야 함
    • REST → 아키텍처 혹은 방법론과 비슷 ⇒ 이런 방식을 사용해야함!!!! 하며 강제적 X
      • 기존의 웹 서비스처럼 GET을 이용해 UPDATE or DELETE 가능
    • REST 아키텍쳐에 부합하지 않으므로 REST를 따른다고 할 수 없음
  3. 자기 서술적이어야 함
    • 데이터에 대한 메타 정보만을 가지고도 어떤 종류의 데이터인지, 데이터를 위해서 어떤 애플리케이션을 실행 해야 하는지를 알 수 있어야 함
    • 데이터 처리를 위한 정보를 얻기 위해서, 데이터 원본을 읽어야 한다면 자기 서술적이지 못 함
  4. HATEOS
    • Hypermedia as the Engine of Application State
    • 클라이언트 요청에 대해 응답을 할 때, 추가적인 정보를 제공하는 링크를 포함할 수 있어야 함
    • REST는 독립적으로 컴포넌트들을 손쉽게 연결하기 위한 목적으로도 사용됨
    • 서로 다른 컴포넌트들을 유연하게 연결하기 위해선, 느슨한 연결을 만들어 줄 것이 필요함
    • 이 때 사용 되는 것 == 링크
      • 서버는 클라이언트 응용 애플리케이션에 하이퍼링크를 제공함
    • 클라이언트는 이 하이퍼 링크를 통해 전체 네트워크와 연결되며 HATEOAS는 서버가 독립적으로 진화할 수 있도록 서버와 서버, 서버와 클라이언트를 분리할 수 있게 함