[BackEnd] REST API

REST API

REST API는 설계 원칙인 REST를 기반으로 설계된 API입니다. 
그럼 REST와 API는 무엇일까요?

REST

REST는 Representational State Transfer의 약자로, 직역하면 "대표 상태 이전" 입니다.

설명하자면  REST는 사용자, 게시글 등에 해당하는 자원을 URI로 식별하고

Delete, Post와 같은 HTTP 메서드를 사용하여 자원을 조작하는 방식을 말합니다.
웹의 표준 프로토콜인 HTTP를 사용하여 자원이 저장되어있는 서버와 사용자인 클라이언트 사이를 통신하기 때문에 

HTTP의 메서드와 같은 기본 기능들을 그대로 활용해서 사용하여 통신하게 됩니다. 

REST는 특정 프로토콜에 종속되지 않기 때문에 HTTP가 아니어도 다른 전송 방식을 사용 할 수 있지만 

REST의 특징이 HTTP와 너무 잘 맞기 때문에 대부분의 REST API는 HTTP를 기반으로 구현되게 됩니다.

 

REST의 6가지 제약조건이 있습니다. 이는 REST 아키텍처 스타일을 정의하는 핵심 요소입니다.

이 제약조건들은 시스템의 확장성, 성능, 단순성, 모듈성 등을 높이기 위해 정의된 조건 입니다.

 

1. 클라이언트 - 서버 구조
   이 조건은 클라이언트와 서버를 명확히 분리하기 위해 만들어진 조건 입니다.
   클라이언트는 사용자 인터페이스와 사용자 경험을 책임지게 되고,
   서버는 데이터 저장 및 비즈니스 로직을 담당합니다.
   역할 분리 덕분에 독립적인 개발이 가능하고 유지보수와 확장성이 좋아진다는 장점이 있습니다.
   
   예) 쿠팡 앱은 UI를 변경해도 서버 로직은 건드릴 필요 없고, 반대로 서버가 상품 정보를
   처리하는 방식이 바뀌어도 사용자 UI는 그대로 유지해도 된다. 
   
   
2. 무상태성
   서버는 요청 간의 상태를 저장하지 않는다는 원칙 입니다.
   클라이언트가 서버에 요청 할 때 모든 정보를 포함해서 보내야 합니다.
   서버는 요청을 받았을 때 과거의 요청 정보를 기억하지 않는다. 이러한 특징을 가진 원칙 입니다.
   서버가 클라이언트의 상태를 기억하지 않기 때문에 서버 확장이 쉬워진다는 장점이 있습니다.
   
   예) 네이버 뉴스 댓글을 달 때, 매 요청마다 로그인 토큰이 포함되어 서버가 사용자를 인식하고
   허용 여부를 판단함. 서버는 상태를 기억하지 않는다.
   
   
3. 캐시 가능
   응답은 캐싱이 가능한지 아닌지를 명확히 표시해야 한다는 원칙 입니다.
   클라이언트는 서버 응답에 따라 경과를 저장하고, 다음 요청에서
   서버 대신 캐시된 데이터를 사용 할 수 있다는 원칙 입니다.
   트래픽이 감소하고, 응답 시간이 개선되며 서버 부하가 감소한다는 장점이 있습니다.
   
   예) 인스타그램에서 같은 게시물을 빠르게 다시 열 때, 로딩이 빠른 이유는 캐시 때문이다.
   
   
4. 계층화 시스템
   REST 시스템은 여러 계층으로 구성 될 수 있으며 클라이언트는 중간 계층의 존재를 알지 못한다는 원칙 입니다.
   클라이언트는 서버에 직접적으로 요청하는 것처럼 보이지만 실제로는
   프록시, 로드밸런서, 인증 서버 등을 거쳐 요청이 전달될 수 있다는 원칙 입니다.
   보안, 로드밸런싱, 캐싱 등의 다양한 중간 기능을 계층 구조로 추가하여 구현 할 수 있다는 장점이 있습니다.
   
   예) 사용자는 https://hej090224.tistory.com/ 같은 URL만 요청하지만,
   실제로는 로드밸런서 → 인증 → 메뉴 데이터 서버 순으로 거쳐 처리된다.
   
   
5. 일괸된 인터페이스
   이 원칙은 REST 방식의 핵심인 원칙이라고도 할 수 있을만큼 중요한 원칙입니다.
   클라이언트와 서버 간의 상호작용은 일관된 방식으로 수행되어야 한다는 원칙으로,
   REST 시스템이 다른 아키텍쳐와 구별되는 가장 큰 특징이라 할 수 있고
   아래 4가지의 하위 요소로 나뉘게 됩니다.
   - 자원의 식별: URI로 자원을 고유하게 식별해야 함
   - 자원의 표현 전달: JSON, XML 등으로 자원의 상태를 전달
   - 자원에 대한 행위는 표현이 아닌 메서드로 표현 해야함(POST, GET 등)
   - 하이퍼미디어: 응답에 링크를 포함하여 클라이언트가 다음 행동을 경정 할 수 있게 함(선텍사항)
   
   예) GitHub API를 사용하면 사용자 정보, 저장소 정보 등
   모두 동일한 형식의 URI와 응답 구조로 제공합니다. 개발자가 배우기 쉽고 일관성 높다.
   
   
6. 코드 온 디맨드 (선택사항)
   클라이언트가 서버로부터 실행 가능한 코드를 내려받아 실행 할 수 있다는 원칙입니다.
   이 원칙은 필수적으로 지켜야 할 원칙이 아닌 선택적인 원칙입니다.
   클라이언트 기능을 유연하게 확장 할 수 있다는 장점이 있습니다.
   
   예) 거리 측정 기능을 처음 클릭했을 때 필요한 코드가 서버에서 내려와
   브라우저에서 동작함. 이는 ‘코드 온 디맨드’의 사례이다.
   
   

API

API는 소프트웨어 안에서 애플리케이션들이 서로 통신하고 데이터를 주고 받을 수 있게 하는 규칙 또는

프로토콜들의 집합입니다. 만약 우리가 맥도날드 드라이브 스루를 가서 빅맥을 시킨다면 우리는

메뉴판(API 명세)을 보고 -> 빅맥을 주문(요청) -> 빅맥이 나옴(응답) 이렇게 내부에서 무슨 일이 일어났는지는 알지 못해도

우리는 요청만 해도 원하는 응답을 얻을 수 있습니다. API에는

- OS API: 운영체제에서 제공하는 기능
- Library API: 프로그래밍 라이브러리
- Web API: 네트워크를 통해 HTTP로 통신하는 API

등의 종류가 있는데 REST API는 Web API에 해당합니다.
즉 API는 TV의 리모콘과 같은 역할을 하는 "기능을 외부에 제공하는 버튼"이라고 할 수 있습니다.
리모콘의 버튼을 누르면 기능이 동작하게 됩니다. 이때 리모콘은 TV의 시스템에 접근하는 접근수단이자
기능을 실행하는 방식인 것처럼 API도 이와 같은 역할을 하게 됩니다.

 

REST API

REST를 기반으로 하는 API인 REST API는 한마디로 표현하자면
"HTTP를 기반으로 자원을 URI로 표현하고, 메서드로 조작하는 통신 규칙"이라고 표현 할 수 있겠습니다.
REST API는 5가지의 요소로 구성되어 있는데 다음과 같습니다.

 

1. URI - 자원을 식별하는 주소
2. HTTP Method - 자원에 대해 어떤 동작을 할지 결정
3. Request - 클라이언트에서 서버로 보내는 요청
4. Response - 서버가 클라이언트에게 보내는 응답
5. Status Code - 요청에 대한 처리 결과

위는 제가 테스트한 REST API 기반 board crud를 테스트한 Postman 화면 입니다. 
REST API 구성 요소가 모두 보이는 것을 알 수 있습니다. 또한 응답 형식이 JSON인 것도 REST API의 일반적인 특징입니다.

 

즉 REST API는 자원을 URI로 표현하고 동작은 HTTP 메서드를 사용하며 응답은 JSON 형태로 돌아옵니다.
상태 코드를 명확히 사용하여 요청 처리 결과를 직관적으로 파악 가능한 API 입니다.

RESTful API

그렇다면 이름이 비슷한 RESTful API는 무엇일까요?
RESTful API란 REST API와 다른 개념이 아닙니다.

단지 REST 아키텍쳐의 원칙을 잘 지킨 상태를 RESTful이라고 부릅니다.
자원 중심 URI, HTTP 메서드의 의미 준수, 무상태성 등 REST의 핵심 규칙을 잘 지키고

설계된 API를 RESTful API라고 부릅니다. RESTful이 되려면 지켜야하는 사항이 있는데 다음과 같습니다.

1. URI는 자원 중심이어야 한다.
2. HTTP 메서드 사용을 올바르게 해야 한다.
3. 무상태(Stateless)해야 한다
4. 응답은 일관된 포맥으로 하고 상태코드를 명확히 사용 해야한다.

RESTful API와 REST API의 차이점

REST 아키텍쳐 스타일을 따라 만든 API도 REST API라고 할 수 있습니다. 하지만

RESTful API는 REST의 6가지 제약조건과 철학을 잘 지켜서 설계된 API만 RESTful API라고 부를 수 있습니다.

 

예를 들어서 HTTP로 요청하고 응답하는 APi지만 올바르지 않은 URI를 사용하거나
POST 메서드로 삭제하는 등의 API는 RESTful API라고 부를 수 없습니다.
하지만 REST API 중에서도 URI를 자원중심으로 설계하고, HTTP메서드를 의미에 맞게 사용하고,
상태 코드와 응답 구조가 일관되며 명확하고, 서버가 무상태이면 RESTful API라고 부를 수 있습니다.

 

REST API라는 큰 틀 안에 규칙을 잘 지킨 RESTful API가 있다고 생각하면 될 거 같습니다.

비유로 설명하며 마무리 하자면 REST API는 "옷을 입긴 한 상태" 이고,

RESTful API는 "옷을 잘 갖춰서 멋있게 입은 상태" 이정도로 말 할 수 있을 거 같습니다.

 

RESTful API를 만들기 위해서는 개발자의 역량이 중요하다고 할 수 있습니다. RESTfu 하게 API를 설계하려면

HTTP에 대한 깊은 이해, API 설계 능력, 팁과 협업할 수 있는 명확한 문서화 능력 등이 요구됩니다.

즉 RESTful API는 단순한 구현이 아니라 개발자의 설계럭, 이해력, 경험이 반영된 결과라고 할 수 있습니다.

REST API는 누구나 만들 수 있지만 RESTful API는 잘 아는 사람만이 제대로 만들 수 있는 "잘 설계된 API"입니다.

이상으로 블로그를 마치겠습니다. 읽어주셔서 감사합니다.