REST - Representational State Transfer

  • 하나의 아키텍쳐
  • API 설계의 중심에 resources(자원)을 놓는 형태
  • URI를 통해 리소스를 표현
  • HTTP Method를 이용하여 행위를 규정하고 응답받음
    • HTTP 대표 4가지 method
    • GET - 읽기
    • POST - 쓰기
    • PUT - 수정
    • DELETE - 삭제
흔히 RESTful 하다는 말 -> REST 기본원칙을 성실히 지킨 서비스 디자인!!

REST 기본원칙 6가지

1. Client - Server

  • 클라이언트 - 서버 구조
  • 아키텍쳐를 단순화 시키고 더 작은 단위로 분리
  • 클라이언트 : request(요청) -> 고객은 URL만 알면 서버의 자료를 알 수 있음
  • 서버 : response(응답)
  • 클라이언트와 서버간 개발할 내용이 명확해지고 서로 간에 의존성이 줄어듬

2. Stateless

  • 무상태
  • 각 요청 간 클라이언트의 컨텍스트가 서버에 저장되면 안됨 -> HTTP 요청에 대한 어떤 것도 저장 X
  • 즉 세션은 전적으로 클라이언트에 유지
  • 확장을 쉽게할 수 있음

3. Cacheable

  • 캐시 처리 가능
  • HTTP 요청을 통해 보내는 자료들은 캐싱이 가능해야 함
  • HTTP Header에 있는 cache-control
  • 서버의 response(응답)를 캐싱하여 서버와 클라이언트 간의 처리를 줄이고, 성능과 서버 가용성 늘어남
가용성(Availability) : 서버와 네트워크, 프로그램 등의 정보 시스템이 정상적으로 사용 가능한 정도

4. Uniform Interface

  • 일관적 인터페이스
  • 4가지 제약을 따라야 함
    1. Identification of Resources (리소스 식별) 
      • 리소스가 URI로 식별되어야 함
    2. Manipulation of Resource through Representations (표현을 통한 자원 조작)
      • 어떠한 리소스에 대해 작업하기 위한 적절한 표현과 데이터를 갖추고 있다면
      • 서버는 해당 리소스를 변경, 삭제할 수 있는 정보를 가지고 있다
      • GET, POST, PUT, DELETE 등을 활용해 리소스 조작 가능
    3. Self-descriptive messages (자기 서술적인 메세지)
      • 자신을 어떻게 처리해야하는지 정보를 포함해야 함
      • HTTP 메세지만 보고 파악할 수 있을 정도의 정보!!
    4. Hypermedia as the engine of application state (HATEOAS)
      • hyperlink를 이용해 전이되어야 함
      • 특정 리소스가 다른 리소스와 관련이 있을 때,
      • 다른 리소스의 정보를 가져올 수 있게 URI를 의미하는 링크를 포함

5. Layered System

  • REST는 다중 계층 구조를 가질 수 있도록 허용
  • 쉽게 말하면 요청, DB(저장, 연결)하는 곳을 여러가지 단계를 거쳐서 처리가능
  • 클라이언트는 REST 서버와 상호작용을 하고, REST가 상호작용하는 중간 레이어, 서버를 모름

6. Code on Demend

  • 서버는 클라이언트에 실행가능한 코드를 전송할 수 있다
  • 사전에 필요한 기능의 수를 줄여서 클라이언트를 단순화 함

RESTful API

  • REST 기본 원칙을 성실히 지킨 서비스 디자인
  • 자원의 식별이 가능
  • 리소스와 행위의 명시
    • URI로 표현되는 리소스
      • URI 설계 개념 (되도록 명사 사용)
      • Document(문서) - 하나의 객체, 단수
      • Collection(컬렉션) - 객체들의 집합, 복수
      • Store(스토어) - 리소스들이 관리되는 저장소
      • Controller - 위 세개로 해결하기 어려운 추가 프로세스 실행, 동사를 사용하기도 함
  • header와 body의 분리

RESTful API naming

  1. 리소스 표현은 명사 사용
  2. 일관성을 유지하자
    • 계층 관계를 '/' 로 나누어 표현
    • 마지막 문자 '/' 사용 X
    • 뛰어쓰기는 '_' 말고 '-' 사용
    • 소문자
    • 파일  확장자 사용 X
  3. CRUD 단어 사용 X
    • URI는 동작이 아니라 리소스를 가르킴
    • HTTP Method를 이용해서 가르키기
  4. 쿼리 파라미터 사용
    • 정렬, 필터, 페이징은 새로운 API를 만들지 말고 쿼리 파라미터 사용
복사했습니다!