[Backend] RESTful API란, API와 Interface

REST/Restful API란?

REST 아키텍처 스타일의 디자인 원칙을 준수하는 API다.

 

 

REST 디자인 원칙

1. 균일한 인터페이스
2. 클라이언트-서버
3. Stateless
4. 캐싱 가능성
5. 코드 온디맨드

• HTTP URI를 통해 자원(resource)을 명시
• 해당 자원에 대해 HTTP 메소드를 활용해서 CRUD 기능을 수행

HOW TO UNDERSTAND

• API
• REST
• REST/RESTful API

 

에 대한 이해가 기반되어야 한다.

 

---

Interface(상호의 얼굴 😃)

(사전상) 컴퓨터 프로그램이 user와 주고받는 정보를 나타내는 방법

• 메뉴/스크린의 레이아웃
• GUI(Graphical User Interface): 사용자가 편리하게 사용할 수 있도록 컴퓨터의 어떠한 기능을 아이콘 따위로 나타낸 것
• (결론) 어떤 두 시스템, 장치, 소프트웨어 따위를 서로 이어주는 부분으로 사용자와 컴퓨터를 이어주는 장치는 모니터와 마우스, 스크린 등이 있다!
• 자바 언어를 사용하는 개발자에게 Interface란 주로 클래스와 유사한 구조를 띄면서, 추상 메서드와 상수만을 정의하는 참조 타입. → 어떤 클래스가 공통적으로 사용하는 메서드나 상수를 정의하기 위해서 사용된다.
  • 이러한 인터페이스를 보고, 해당 인터페이스가 실제로 구현된 클래스에서 어떤 작용을 하는지 유추가능하다. 또한 구현 클래스 내용을 모르더라도 인터페이스만 알면 해당 메소드를 사용할 수 있다.

 

---

API(Application Programming Interface)

말 그대로, 두 애플리케이션 프로그래밍이 서로 통신하기 위해 정의된 규칙이다.

이러한 API 아키텍처(구조)는 일반적으로 클라이언트와 서버 측면에서 설명된다.

• 클라이언트: 어떤 작업을 위해 요청을 보내는 애플리케이션(ex. API를 사용하는 사람, 소프트웨어 시스템)
• 서버: 요청에 대한 응답을 보내는 애플리케이션

 

예를 들어 메일 발송 기능을 구현한다고 가정할 때,

1. 클라이언트는 메일을 작성하고 메일을 발송하는 요청을 서버측으로 보낸다.
2. 서버는 API를 통해서 클라이언트가 원하는 작업에 대한 정보를 수행 및 제공한다.
3. 클라이언트는 이 정보를 사용해서 메일 발송 여부를 확인하고, 추가적인 요청을 서버에 보낸다.

API는 이렇게 클라이언트와 서버의 상호작용을 원활하게 도와주는 역할을 수행한다.

 

---

REST

REST 구성요소
CRUD와 HTTP Method
REST API가 지켜야하는 스타일
목적, 장단점, 필요한 이유

 

REST API

 

API 개발자는 여러 아키텍처를 사용하여 API를 설계할 수 있다.

• REST 아키텍처 스타일을 따르는 API를 REST API라고 한다.
• REST 아키텍처를 구현하는 웹 서비스 즉, REST API를 사용한 웹을 RESTful 웹 서비스라고 한다.
• RESTful API라는 용어는 일반적으로 RESTful 웹 API를 나타낸다. 하지만 REST API와 RESTful API라는 용어는 같은 의미로 사용할 수 있다.

REST가 정의한 함수 집합은 GET, POST, PUT, DELETE 등이 있다. 클라이언트와 서버는 HTTP를 사용하여 데이터를 교환한다.

결론적으로 Restful API는 HTTP URI를 통해 자원(resource)을 명시하고, HTTP 메소드를 활용해서 해당 자원에 대한 CRUD 기능을 수행하도록 도와주는 웹 서비스 디자인 패턴이다.

• 웹 사이트의 이미지, 텍스트, DB 내용 등 모든 자원에 고유한 ID인 HTTP URI를 부여한다.

 

REST 구성 요소

[Network] REST란? REST API란? RESTful이란? - Heee's Development Blog

1. 자원(Resource): URI
   • 모든 자원에 고유한 ID가 존재하고, 이 자원은 서버에 존재한다.
   • 자원을 구별하는 ID는 ‘/groups/:group_id’와같은 HTTP URI다.
   • 클라이언트는 URI를 이용해서 자원을 지정하고 해당 자원의 상테에 대한 조작을 서버에 요청한다.
2. 행위: HTTP Method
   • HTTP 프로토콜의 Method를 사용한다.
   • HTTP 프로토콜은 GET, POST, PUT,DELETE 등과 같은 메서드를 제공한다.
3. 표현(Representation of Resource)
   • Client가 자원의 상태에 대한 조작을 요청하면 서버는 이에 적절한 응답(Representation)을 보낸다.
   • REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등의 여러 형태(Representation)로 나타내어진다.

 

RESTful API 패턴 | CRUD와 HTTP method

CRUD HTTP method

Create(생성)	POST
Read(조회)	GET
Update(수정)	PUT
Delete(삭제)	DELETE
HEAD(헤더 정보 조회)	HEAD

 

RESTful API가 지켜야하는 스타일

 

Client-Server

• 클라이언트와 서버는 서로 간에 완전히 독립적이어야 한다. 클라이언트 애플리케이션이 알아야 하는 유일한 정보는 요청된 리소스의 URI이며, 다른 방법으로는 서버와 상호작용할 수 없다.

Stateless

• 각 요청의 처리에 필요한 모든 정보를 포함해야 하며, 세션과 쿠키같은 정보를 저장하지 않는다.

Cacheable

• 리소스를 클라이언트나 서버측에서 캐싱할 수 있어야 한다. → 웹 표준 HTTP 프로토콜을 사용하므로 웹에서 사용하는 기존의 인프라를 그대로 활용할 수 있다. (캐싱은 HTTP가 가진 강력한 특징 중 하나

Uniform Interface

• 리소스가 URI로 식별되어야 한다.
• 리소스를 생성,수정,추가하고자 할 때 HTTP 메시지에 표현을 해서 전송해야 한다.
• 메시지는 스스로 설명할 수 있어야 한다.
• 애플리케이션의 상태는 Hyperlink를 통해 전이되어야 한다.
• 응답 결과에 보통 JSON을 사용하게 되는데, 이 JSON 메시지가 어디에 전달되는지 그리고 JSON 메시지를 구성하는 것이 어떤 의미를 표현해야만 메시지 스스로 설명할 수 있다고 말할 수 있다.

https://www.youtube.com/watch?v=RP_f5dMoHFc&t=3s

 

Layered Systerm

• Client는 REST API Server만 호출한다.
• REST 서버는 다중 계층으로 구성될 수 있다.
  • 로드밸런싱, 공유 캐시 등을 통한 확장성 및 보안성
  • API 서버는 순수 비즈니스 로직 수행의 앞단에 보안, 암호화, 로드밸런싱 등 추가 가능

Code-On-Demand

• 서버로부터 스크립트를 받아서 클라이언트에서 실행한다.

 

---

RESTful API 목적

• RESTful API를 구현하는 근본적인 목적은 일관적인 컨벤션을 통한 API의 이해도 및 호환성을 높이는 것이다.
• 따라서 성능이 중요한 상황이나, REST API 스타일을 지키지 못하는 상황에서 반드시 RESTful한 API를 구현할 필요는 없다.(그런 REST API로 괜찮은가)

 

REST의 장단점

장점

• HTTP 프로토콜 인프라를 그대로 사용하므로 별도의 인프라를 구축할 필요가 없다. (Cacheable)→ HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용 가능
• → HTTP 프로토콜 표준의 장점 그대로 활용
• REST API 메시지가 의도하는 바를 명확하게 나타내므로, 의도를 쉽게 파악할 수 있다.
• 서버와 클라이언트의 역할 독립

단점

• 표준이 없다.
• 사용할 수 있는 메소드 형태가 제한적이다.
• 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 값이 웬지 더 어렵다. (API 설계해보면 바로 알 수 있는…)

⇒ HTTP 헤더에 인증 등을 넣어본 경험 (x), 스터디하면서 ~에 대해 들어본 경험이 있습니다.

⇒ 헤더에 값을 넣었던 예시.

⇒ 나의 경험을 말하려면 그 경험을 말할 수 있도록 암기.

 

 

REST API가 필요한 이유

• 최근 서버 프로그램은 다양한 프라우저, 모바일 디바이스에서도 통신을 할 수 있는 형태이어야 한다.
• 이러한 멀티 플랫폼의 서비스 자원에 대한 아키텍처를 세우고 이용하는 방법