1. REST

REpresentational State Transfer의 약자로 웹의 장점을 최대한 활용할 수 있는 아키텍처로서 HTTP 주요 저자 중 1명이 논문에 등장한 용어이다.

1-1. REST API의 구성

• 자원: RESOURCE = URI
• 행위 : Verb = HTTP METHOD
• 표현 : Representations

1-2. REST의 특징

✔️ Uniform interface ( 유니폼 인터페이스 )
URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일
✔️ Stateless ( 무상태성 ) - HTTP 기반 속성!
작업을 위한 상태정보를 따로 저장하고 관리하지 않음

• API 서버는 들어오는 요청만을 단순히 처리 ( 세션 정보, 쿠키 정보 등 별도 저장 X )
• 서비스의 자유도가 높아지고 구현이 단순해짐 ( 서버에서 불필요한 정보 관리 X )
  ✔️ Cacheable ( 캐시 가능 ) - HTTP 기반 속성!
  HTTP라는 기존 웹표준을 그대로 사용하기 때문에, 웹에서 사용하는 기존 인프라를 그대로 활용 가능
  -> HTTP가 가진 캐싱 기능 적용 가능
  ✔️ Self-descriptiveness ( 자체 표현 구조 )
  REST API 메세지만 보고도 이를 쉽게 이해 할 수 있는 자체 표현 구조로 되어있음
  ✔️ Client - Server 구조
  서버는 API 제공 / 클라이언트는 사용자 인증이나 컨텍스트 ( 세션, 로그인 정보 ) 등을 직접 관리하는 구조로 각각의 역할이 확실히 구분되기 때문에 클라이언트와 서버에서 개발해야 할 내용이 명확
  -> 서로의 의존성 감소
  ✔️ 계층형 구조
  다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 PROXY, 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있게 함

2. REST API 설계 시 가장 중요한 항목

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

2-1. REST API 중심규칙

✅ 자원 표현 / HTTP Methods = 행위에 대한 정의

• URI는 정보의 자원을 표현해야 함 ( 리소스 명은 '명사' 사용 )
• 자원에 대한 행위는 HTTP Method ( GET, POST, PUT, DELETE ) 으로 표현
  - POST: 해당 URI를 요청하면 리소스를 생성 =Create
  - GET: 해당 리소스를 조회하고 해당 도큐먼트에 대한 자세한 정보를 가져옴 =Read
  • PUT: 리소스 수정 =Update
  • DELETE: 리소스 삭제 =Delete
  • GET/members/delete/1 -> DELETE/members/1

2-2. RESTful API?

• Endpoint를 다양한 resources에 맞게 각각 나누어 설정하였는가?
• HTTP Methods를 통한 자원에 대한 정의가 적절한가? 모든 요청에 적절한 method를 사용하였는가?
• 응답에 대한 메타데이터를 body에 포함하지 말 것!
• URI에 동사가 포함되지 않도록 할 것! -> URI와 HTTP Method 분리, URI는 명사형으로 작성
• RESTful 설계 컨셉: 시스템에서 제공하는 resource를 bucket화 하는 것 !