REST API

Rest 란 무엇인가?

 

REST (REpresentational State Transfer)

 

REST는 표현 상태 전송의 약자이자 분산형 하이퍼미디어 시스템(distributed hypermedia systems)의 아키텍처 스타일이라고 한다.

"Roy Fielding"이 2000년에 그의 유명한 논문에서 발표 후 웹 기반 API(애플리케이션 프로그래밍 인터페이스)를 구축하는 데 가장 널리 사용되는 접근 방식 중 하나가 되었다.

REST는 프로토콜이나 표준이 아니라 아키텍처 스타일이다.

개발 단계에서 API 개발자는 다양한 방식으로 REST를 구현할 수 있다.

다른 아키텍처 스타일과 마찬가지로 REST에도 기본 원칙과 제약 조건이 있는데,

`서비스 인터페이스를 RESTful` 이라고 지칭하려면 이러한 원칙을 충족해야한다.

 

REST 아키텍처 스타일을 따르는 웹 API 또는 WEB SERVICE 를 `REST API` 또는 `RESTful API` 라고 한다.

 

REST 의 6가지 지침 원칙

REST는 설계에서 단순성, 확장성 및 무상태성을 촉진하는 몇가지 제약가 원칙을 기반으로 한다. 

 

1. 균일한 인터페이스 

일반성의 원칙을 구성 요소 인터페이스에 적용함으로써
➡️ 전체 시스템 아키텍처를 단순화하고 상호작용의 가시성을 개선할 수 있다.
➡️ 여러가지 아키텍처 제약 조건은 균일한 인터페이스를 얻고 구성 요소의 동작을 안내하는데 도움이 된다. 

- 리소스 식별 :
   인터페이스는 클라이언트와 서버 간 상호작용에 관련된 각 리소스를 고유하게 식별해야한다.

- 표현을 통한 리소스 조작:
   리소스는 서버 응답에서 균일한 표현을 가져야한다. 

- 자체 설명 메시지:
   각 리소스 표현은 메시지를 처리하는 방법을 설명하는데 충분한 정보를 전달해야한다.

- 애플리케이션 상태의 엔진으로서의 하이퍼 미디어:
   클라이언트는 애플리케이션의 초URI만 가져야한다. 
   클라이언트 애플리케이션은 하이퍼링크를 사용해 다른 모든 리소스와 상호 작용을 동적으로 구동해야한다.

더 간단하게 말하면,
REST는 클라이언트와 서버간의 상호작용을 위해 일관되고 균일한 인터페이스를 정의한다. 
예를 들어,
HTTP 기반 REST API는 표준 HTTP메서드(GET, POST, PUT, DELETE, PATCH)와 URI를 사용해 리소스를 식별한다.

 

2. 클라이언트 ↔️ 서버

클라이언트 ↔️ 서버 디자인 패턴은 관심사 분리를 강화해 클라이언트와 서버 구성 요소가 독립적으로 발전하는데 도움이 된다.
➡️ 사용자 인터페이스 문제(클라이언트)와 데이터 저장 문제(서버)를 분리함으로써,
    여러 플랫폼에서 사용자 인터페이스의 이동성이 향상되고, 서버 구성요소 단순화되어 확장성도 개선된다.
➡️ 클라이언트와 서버가 발전하더라도 클라이언트와 서버 간의 인터페이스/계약이 끊어지지 않도록 해야 한다.

 

3. 무국적

- 무상태화는 클라이언트에서 서버로 보내는 각 요청에 요청을 이해하고 완료하는데 필요한 모든 정보를 포함해야 한다.
- 서버는 이전에 서버에 저장된 컨텍스트 정보를 활용할 수 없다.
- 이러한 이유로 클라이언트 애플리케이션은 세션 상태를 완전히 유지해야 한다.

 

4. 캐시 가능

- 캐시  가능 제약은  응답이 암시적 또는 명시적으로 자신을 캐시 가능 또는 캐시 불가능으로 표시해야 함을 요구 한다.
- 응답이 캐시 가능한 경우 클라이언트 애플리케이션은
   나중에 동일한 요청에 대해 지정된 기간 동안 응답 데이터를 재사용할 권한을 얻는다.

 

5. 계층 시스템

계층 시스템 스타일은 구성 요소의 동작을 제한하고 아키텍처를 계층적 계층으로 구성할 수 있도록 한다. 
계층적 시스템에서 각 구성 요소는 상호 작용하는 바로 그 계층 너머를 볼 수 없다. 

계층화된 시스템의 예로 MVC 패턴이 있다. 
MVC 패턴은 관심사를 명확하게 분리할 수 있고, 애플리케이션 개발, 유지 관리 및 확장하기가 더 쉽다.

 

6. 주문형 코드(선택사항)

REST를 사용하면 애플릿이나 스크립트 형태로 코드를 다운로드하고 실행하여 클라이언트 기능을 확장할 수 있다.

다운로드된 코드는 사전 구현해야 하는 기능의 수를 줄여 클라이언트를 간소화 한다.
서버는 코드 형태로 클라이언트에 전달되는 기능의 일부를 제공할 수 있으며, 클라이언트는 코드만 실행하면 된다.

 

 

리소스란 무엇인가

 

REST에서  정보의 핵심 추상화는 리소스 이다.

이름을 붙일 수 있는 모든 정보는 리소스가 될 수 있다.

 

예를 들어, REST 리소스는 문서나 이미지, 임시 서비스, 다른 리소스 모음 또는 가상이 아닌 객테(예: 사람)가 될 수 있다.

특정 시점의 리소스 상태를  리소스 표현 이라고 한다.

 

리소스 표현은 아래와 같이 구성된다.

• 데이터 ​
•  데이터를 설명하는 메타 데이터 
• 그리고  클라이언트가 원하는 다음 상태로 전환하는데 도움이 되는 하이퍼미디어 링크로 구성된다.

REST API는 상호 연결된 리소스의 집합으로 구성되는데,  이 리소스 집합을 REST API  리소스 모델 이라고 한다.

 

 

리소스 메서드

 

REST와 관련된 또 다른 중요한 것은 리소스 메서드이다.

리소스 메서드는 리소스의 두 상태 간에 원하는 전환을 수행하는 데 사용된다.

이상적으로는 리소스 상태를 전환하는 데 필요한 모든 것이 리소스 표현의 일부가 되어야 하며, 

지원되는 모든 메소드와 어떤 형태로 표현을 남길지 포함해야 한다.

초기 URI(북마크)와 의도된 대상에 적합한(즉, API를 사용할 수 있는 모든 클라이언트가 이해할 수 있을 것으로 예상되는) 표준화된 미디어 유형 세트 이외의 사전 지식 없이 REST API를 입력해야 한다.

이 시점부터 모든 애플리케이션 상태 전환은 수신된 표현에 존재하는 서버 제공 선택 사항의 클라이언트 선택 또는 사용자의 해당 표현 조작에 의해 암시된 선택에 의해 이루어져야 한다.

이러한 전환은 

미디어 유형 및 리소스 통신 메커니즘에 대한 클라이언트의 지식에 의해 결정, 제한될 수 있다. 이 두 가지 모두 즉석에서 개선될 수 있다.

 

 

REST와 HTTP는 같지 않다. 

 

REST != HTTP

REST는 웹을 더 간소화하고 표준화하려는 의도를 가지고 있다

하지만 "Roy Fielding"는 REST 원칙을 더 엄격하게 사용할 것을 주장한다. 

 

간단하게 REST는 아키텍쳐 스타일이고 HTTP는 그 중 하나의 구현 방법이다.

RESTful 시스템의 대부분이 HTTP를 사용해 구현되어 있는 것 일 뿐 이므로 혼돈하지 말자.

 

 

결론..!!

 

`API(Application Programming Interface)`

➡️ 소프트웨어가 비지니스 운영을 위해 다른 소프트웨어와 상호 작용할 때 준수하기로 한 약속한 계약

➡️ 두개 이상의 소프트웨어 애플리케이션이 잘 정의된 컴퓨팅 인터페이스를 통해 서로 통신 할 수 있도록 하는 것.

 

회원가입, 로그인, 글 목록들 보기,글 작성, 글 수정, 글 삭제 등등 특정 기능들은 

1. 클라이언트가  Request 하면,

2. 백엔드 서버의 API 들이 요청에 맞는 기능을 실행하고

3. 지정된 형식으로 적절한 Response 를 보내준다.  

 

`Rest API(Representational State Transfer)`

➡️ 인터넷과 웹을 통해 나의 컴퓨터를 제어할 때 어떻게 효율적으로 API를 동작시킬 수 있는 가에 대한 고민과 결과!

 

내 컴퓨터에서  다른 사람의 컴퓨터에 Request 하고

다른 사람의 컴퓨터가 나의 Request를 이해하고 적절한 Response를 주기 위해서는 통일된 규칙이 있어야 한다.

서로 다른 컴퓨터가 소통을 하기 때문에 규칙이 없다면, 서로의 Request 와 Response를 이해할 수 없을 것이다.

 

 

참고자료 
https://restfulapi.net/what-is-an-api/