Today I Learned

오늘은 항상 헷갈리던 REST에 대해 제대로 정리해보았다.

참고 사이트 : dev-coco

REST

REpresentational State Transfer
자원을 이름으로 구분해 해당 자원의 상태를 주고 받는 모든 것

• 자원의 표현에 의한 상태 전달

• 분산 시스템에서 자원을 나타내고, 자원에 대한 상태를 전송하기 위한 아키텍쳐 스타일.

• URI와 HTTP를 이용한 통신 목적의 서버-클라이언트 아키텍처 스타일

• 주로 HTTP 프로토콜을 사용하지만 그외 다양한 프로토콜을 지원할 수 있다.

구성요소

• 자원 : Resource. 해당 SW가 관리하는 모든 것. URI로 식별된다.

• 행위 : Verb. HTTP의 Method. CRUD(GET, POST, PUT, PATCH, DELETE)

• 표현 : Representation. 그 자원을 표현하기 위한 이름
  클라이언트가 서버와 데이터를 주고받는 형태로 JSON, XML 등이 있다.

특징

• Server - Client 구조
  자원이 있는 쪽이 서버, 자원을 요청하는 쪽이 클라이언트.
  클라이언트가 서버에 요청을 보내고, 서버가 클라이언트에게 응답을 보낸다.

• Stateless
  클라이언트의 context(문맥)를 서버에 저장하지 않고, 그것 없이도 통신할 수 있다.
  서버는 각각의 요청을 별개의 것으로 인식하고 처리한다.

• Cacheable
  서버의 응답 메세지는 캐싱(저장 후 재사용)할 수 있다.
  HTTP의 기능인 캐싱을 적용할 수 있어 대량의 요청을 효율적으로 처리한다.

• 계층 구조(Layered System)
  REST 서버는 다중 계층으로 구성될 수 있다.
  보안, 로드밸런싱, 암호화 등을 위한 계층을 추가해 구조를 변경할 수 있다.(ex. Proxy, Gateway)
  중간 계층이 변경되어도 통신에 영향을 주지 않는다.

• Uniform Interface
  URI로 지정한 자원에 대한 요청을 통일되고 한정적으로 수행한다.
  HTTP 프로토콜을 따르는 모든 플랫폼에서 사용 가능하며, 어떤 기술이나 언어에 종속되지 않는 느슨한 결합 형태를 가진다.

• 주문형 코드 code on demand (선택)
  손쉬운 데이터 처리를 위해 서버는 클라이언트에서 실행될 스크립트를 전송할 수 있다.

REST API

REST의 특징을 기반으로 서비스 API를 구현한 것

• 각 요청이 어떤 동작이나 정보를 위한 것인지 그 요청 자체로 추정이 가능하다.

• URI는 정보의 자원만 표현해야 하며, 자원의 행위는 HTTP Method에 명시한다.

REST API 설계 규칙

1. URI는 명사를 사용한다. 일반적으로 users같은 복수형의 명사를 쓴다.
   ex. URI에 find~ create~ 이런 동사형을 쓰지 않는다.

2. /(슬래시)로 계층 관계를 표현한다.
   ex. /organizations/{orgId}/users/{userId}

3. URI의 마지막 문자로 슬래시를 포함하지 않는다.

4. _(언더바)를 사용하지 않고 -(하이픈)를 사용한다.

5. URI는 소문자로만 구성한다.

6. HTTP Status Code를 사용한다.

7. 파일 확장자는 URI에 포함하지 않는다.

RESTful API

REST API의 설계 규칙을 잘 지켜 만든 API

• self-descriptiveness : RESTful한 API는 요청을 보내는 주소만으로 어떤걸 요청하는지 파악이 가능하다. API 그 자체만으로 API의 목적을 쉽게 알 수 있다.