REST

REST란?
Representational State Transfer의 약자로, 네트워크 리소스를 정의하고 처리하는 방법을 설명하는 일련의 원칙을 기반으로 하는 아키텍처 스타일이다. HTTP를 잘 활용하기 위한 원칙이기도 하다.

✔ REST에 대한 원칙을 준수했을 때, 'RESTful하다' 라고 한다.

REST 구성요소

1. Resource(자원): URI

• 모든 리소스에는 고유한 ID가 존재하고, 이 리소스는 server에 존재한다.

• 리소스를 구별하는 ID는 '/courses/backend/crew'와 같은 HTTP URI이다.

• 리소스를 URI에 표현하여 주고받을 정보에 대해 어느정도 예측 가능하다.

• client는 URI를 이용해 리소스를 지정하고, 해당 리소스의 상태(정보)에 대한 조작을 server에 요청한다.

  ❓ URI와 URL의 차이점?
  URL은 Uniform Resource Locator로 인터넷 상 리소스의 워치를 의미한다.
  반면 URI는 Uniform Resource Identifier로 인터넷 상의 리소스를 식별하기 위한 문자열의 구성으로, URI는 URL을 포함하게 된다. URI가 URL보다 포괄적인 범위라고 할 수 있다.

2. Verb(행위) : HTTP Method

• HTTP 프로토콜의 Method를 사용한다.

  Create ➡ POST
  Read ➡ GET
  Update ➡ PUT or PATCH
  Delete ➡ DELETE

3. Representation of Resoure(표현)

• Client가 리소스의 상태(정보)에 대한 조작을 요청하면 server는 이에 적절한 응답(Representation)을 보낸다.
• REST에서 하나의 리소스는 JSON, XML, TEXT, RSS 등 여러 형태의 Representation으로 나타낼 수 있다.
• JSON 혹은 XML를 통해 데이터를 주고 받는 것이 일반적이다.

REST 특징

1. Server-Client (서버-클라이언트 구조)

• 리소스가 있는 쪽이 server, 리소스를 요청하는 쪽이 client가 된다.
• REST Server: API를 제공하고 비즈니스 로직 처리 및 저장을 책임진다.
• Client: 사용자 인증이나 context(세션, 로그인 정보) 등을 직접 관리하고 책임진다.
• 역할을 구분시켜서 서로 간의 의존성을 줄어들었다.

2. Stateless (무상태)

• HTTP 프로토콜은 Stateless Protocol이므로 REST 역시 무상태성을 갖는다.
• Client의 context를 server에 저장하지 않는다.
• 즉, 세션과 쿠키와 같은 context 정보를 신경쓰지 않아도 되므로 구현이 단순해진다.
• Server는 각각의 요청을 완전히 별개의 것으로 인식하고 처리한다.
• 각 API 서버는 Client의 요청만을 단순처리한다.
• 즉, 이전 요청이 다음 요청의 처리에 연관되어서는 안된다.
• Server의 처리 방식에 일관성을 부여하기 때문에 서비스의 자유도가 높아진다.

3. Cacheable (캐시 처리 가능)

• 웹 표준 HTTP 프로토콜을 그대로 사용하므로 웹에서 사용하는 기존의 인프라를 그대로 활용할 수 있다.
• 즉, HTTP가 가진 가장 강력한 특징 중 하나인 캐싱 기능을 적용할 수 있다.
• HTTP 프로토콜 표준에서 사용하는 Last-Modified Tag 또는 E-Tag를 이용해 캐싱을 구현한다.
• 대량의 요청을 효율적으로 처리할 수 있다.

4. Layered System (계층 구조)

• Client는 REST API Server만 호출한다.
• REST Server는 다중 계층으로 구성될 수 있다.
• 보안, 로드 밸런싱, 암호화 등을 위한 계층을 추가하여 구조를 변경할 수 있다.
• Proxy, Gateway와 같은 네트워크 기반의 중간매체를 사용할 수 있다.
• 하지만 Client는 Server와 직접 통신하는지, 중간 서버와 통신하는지 알 수 없다.

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

• URI로 지정한 리소스에 대한 조작을 통일되고, 한정적으로 수행한다.
• HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.
• 특정 언어나 기술에 종속되지 않는다.

6. Self-Descriptiveess (자체표현)

• 요청 메시지만 보고도 쉽게 이해할 수 있는 자체 표현 구조로 되어있다.

REST API

REST API란?
REST의 특징을 기반으로 서비스 API를 구현한 것
최근 OpenAPI, 마이크로 서비스(하나의 큰 어플리케이션을 여러 개의 작은 어플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처) 등을 제공하는 기업 대부분은 REST API를 제공한다.

✔ REST API의 가장 큰 특징은 각 요청이 어떤 동작이나 정보를 위한 것인지를 그 요청의 모습 자체로 추론이 가능한 것이다.

REST API 디자인 가이드

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

1. URI는 정보의 리소스를 표현해야 한다.
2. 리소스에 대한 행위는 HTTP Method로 표현한다.

• Method는 URI에 포함하지 않는다.

REST API의 설계 규칙

1. URI는 명사를 사용한다.
2. 슬래시(/)로 계층 관계를 표현한다.
3. URI 마지막 문자로 슬래시(/)를 포함하지 않는다.
4. 밑줄(_)을 사용하지 않고, 하이픈(-)을 사용한다.
5. URI는 소문자로만 구성한다.
6. HTTP 응답 상태 코드를 사용한다.
   (클라이언트는 해당 요청에 대한 실패, 처리완료 또는 잘못된 요청 등에 대한 피드백을 받아야 한다.)
7. 파일확장자는 URI에 포함하지 않는다.