REST?

• WWW와 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍쳐 스타일 중 하나

  • 소프트웨어 아키텍쳐 ?

    시스템을 구성하는 구성 요소(서브 시스템, 컴포넌트)와 그들 간의 관계를 표현하는 구조

    웹의 기존 기술과 HTTP 프로토콜을 이용하는 것에 의의가 있으므로, 웹의 장점을 최대한 활용할 수 있음

• 네트워크 상에서 Client와 Server 사이의 통신 방식 중 하나

• REST (Representational State Transfer)

  → 자원을 고유한 이름으로 구분(자원의 표현)하여 그 표현의 상태를 주고 받는 것을 의미

  • 자원 (Resource)

    소프트웨어가 관리할 수 있는 모든 것

    e.g., 문서, 이미지, 텍스트, 소프트웨어 등등..

  • 자원의 표현 (Representation)

    자원을 식별하기 위한 이름

    e.g.,

    [자원] 여러 학생 정보 → [표현] 'student'

    [자원] 여러 음식 정보 → [표현] 'food'

  • 상태(정보) 전달

    리퀘스트 시점에 해당 자원의 상태(정보)를 전달

    JSON 또는 XML 형식의 데이터를 주고 받는 것이 일반적

REST의 구체적 개념

• REST는 HTTP URI 형태로 자원을 표현

• HTTP 메소드(GET, POST, PUT, DELETE)로 해당 자원에 대한 CRUD 작업을 수행

  → REST는 자원 지향 아키택처(ROA, Resources Oriented Architecture)

장점

• HTTP의 기술과 인프라를 그대로 사용함 → REST API를 위한 별도 인프라 구축 필요 X
• HTTP을 따르는 모든 플랫폼에서 사용이 가능
• HTTP를 통한 하이퍼미디어 범용성을 보장
• REST API 표현이 명확함 → 의미 파악이 쉬움
• 서비스 디자인에 발생 우려되는 문제의 최소화 (HTTP로 일관성이 유지되기 때문)
• 서버와 클라이언트의 역할을 명확하게 분리

단점

• 정해진 (REST) 표준이 없음
• 제한적인 메소드 (CRUD 형태의 한계)
• 구형 브라우저의 문제
  • PUT, DELETE 지원 X
  • pushState 지원 X

REST가 필요한 이유

• 애플리케이션(서비스)의 분리와 통합이 쉬움(레고 블럭과 유사)

• 브라우저에 국한되지 않는 다양한 클라이언트 종류가 가능해짐 (HTTP만 지원된다면 어떤 디바이스던지 OK)

  ⇒ 즉, REST는 멀티 플랫폼 지원을 위한 서비스(자원) 아키택처로 이상적임

구성 요소

• 자원 (Resource)

  서버에 존재하는, HTTP URI로 표현 가능한 모든 데이터

  고유 ID가 존재

  e.g., /students/:student_id

  클라이언트는 URI를 이용하여 특정 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 요청함

• 행위 (Verb)

  HTTP 메소드 → GET, POST, PUT, DELETE ...

• 표현 (Representation)

  JSON, XML과 같이 여러 종류의 표현으로 나타냄

  JSON 또는 XML이 일반적

특징

클라이언트-서버 구조

• 클라이언트

  자원을 요청하는 사이드

  사용자 인증 및 Context(맥락: 세션 또는 로그인된 유저의 정보)를 관리함

• 서버

  자원을 소유한 사이드

  자원을 조작할 수 있는 API를 제공

  비즈니스 로직 처리 및 저장을 담당

Stateless

• REST는 HTTP 프로토콜의 Stateless 특징을 그대로 간직함

• 서버는 각 요청을 독립된 별개의 것으로 간주 (요청 간의 연관성이 부여되서는 안됨)

  ⇒ 서버의 처리방식에 일관성이 생겨 서버가 단순해지고 서비스의 자유도가 높아짐

Cacheable

• REST는 HTTP 프로토콜의 특징인 캐싱을 그대로 사용 가능

  → Last-Modified 태그 등을 이용한 캐싱 구현이 가능

• 캐싱은 트랜잭션의 절약과 기본적인 응답시간이 빨라지므로 전체적인 서버 성능 개선을 야기

Layered System

• REST API 서버를 여러 계층으로 구성할 수 있음

  • 비즈니스 로직을 위한 REST API 서버 앞에 보안, 로드밸런싱, 인증, 암호화 등의 기능을 계층 구조로 추가

    ⇒ 서버의 유연성을 향상시킬 수 있음

• Proxy, 게이트웨이와 같은 중간 매개체를 사용 가능

Code-On-Demand

• 반드시 충족될 필요는 없는 특징
• 서버로 부터 받는 스크립트를 클라이언트에서 실행시키는 것

Uniform Interface

• URI로 지정된 자원에 대한 조작이 HTTP로 인해 통일됨

  →HTTP 프로토콜을 따르는 어떤 플랫폼에서도 이용이 가능

  ⇒ 멀티 플랫폼 지원이 가능해짐

RESTful

• 어떤 웹 서비스가 REST 아키택처를 충분히 적용하고 있음을 나타내는 용어

RESTful 하지 못한 경우

• CRUD 기능을 모두 POST로 처리하는 API

• URI에서 자원, id 외의 부가 정보가 들어가는 경우

  e.g., /users/items/addItem

REST API

• API?

  Application Programming Interface

  → 운영체제, 언어 혹은 어떤 서비스가 자신의 기능을 조작 및 제어할 수 있도록 외부로 제공하는 인터페이스

• RESTful API

  REST를 기반으로 만든 서비스 API

REST API 특징

• REST 기반으로 시스템을 분산시킴 → 서비스 확장성, 재활용성의 증가로 유지보수 및 운용이 편리해짐
• HTTP를 지원하는 프로그래밍 언어라면 손쉽게 클라이언트-서버를 만들 수 있음

REST API 설계 기본 규칙

도큐먼트: 클래스의 인스턴스, 데이터베이스의 레코드와 유사한 개념; 한 개체를 나타냄

컬렉션: 서버에서 관리하는 디렉토리(자원)

스토어: 클라이언트에서 관리하는 자원 저장소

1. URI는 자원을 표현할 것

   • 동사보다 명사, 대문자보다 소문자를 이용할 것
   • 도큐먼트 이름으로 단수 명사를 이용할 것
   • 컬렉션 이름으로 복수 명사를 이용할 것
   • 스토어 이름으로 복수 명사를 이용할 것

2. 자원에 대한 행위는 HTTP 메소드로 표현할 것

   • URI에 HTTP 메소드를 넣지 말 것

     e.g., [GET] /students/delete/1 ⇒ [DELETE] /students/1

   • URI에 행위를 나타내는 동사를 넣지 말 것

     e.g., [GET] /members/show/1 ⇒ [GET] /members/1

   • URI에서 변하는 부분은 고유 값으로 대체할 것 (id와 같은 고유값)

     e.g., [DELETE] /cars/23, [GET] /cars/17

REST API 설계 규칙

1. 슬래쉬(/)는 계층 구조로 이용

   e.g., /animals/dogs/bulldogs

2. 슬래쉬(/)는 마지막 문자 X

3. 하이픈(-)은 가독성 증가를 위해 사용

4. 언더바(_)는 사용 X

5. 소문자 이용

6. 파일확장자 포함 X

7. 자원의 연관 관계가 있을 경우

   /자원1/자원 id/자원2

   e.g., [GET] /users/{user_id}/items