RESTful API 이란?

반응형

 

REST(Representational State Transfer)란?

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

- 클라이언트와 서버 간의 상호작용을 규정

- 여러가지 원칙과 제약 조건을 가진다.

ex ) REST 상태를 가지지 않는 (stateless)통신, 캐시 가능한 응답 등 지향

 

1. HTTP URI를 통해 자원(Resource)을 명시

2. HTTP Method(POST, GET, PUT, DELETE, PATCH 등)를 통해

3. 해당 자원(URI) 에 대한 CRUD opration을 적용하는 것 

 

REST 특징

1. 자원 (Resource) : HTTP URI

2. 자원에 대한 행위(Verb) : HTTP Method

3. 자원에 대한 행위의 내용 (Representations) : HTTP Message Pay Load

 

 

RESTful이란 REST의 원리를 따르는 시스템을 의미한다. 하지만 REST를 썼다고 모두 RESTfull한 것은 아니고 REST API의 설계 규칙을 올바르게 지킨 시스템을 RESTfull하다 말할 수 있다. 

 Bad ex)

- 모든 CRUD 기능을 POST로 처리

- API 혹은 URI 규칙을 올바르게 지키지 않은 API

 

 

REST는 이론적인 원칙과 가이드라인, RESTfull API는 그 원칙과 가이드라인을 실제 적용한 API라고 이해하면 편하다.

 

 

RESTful의 기본 원칙은 자원을 URL로 표현하고, 그 자원에 대해 HTTP 메서드를 사용해 작업을 수행하는 거다.

예를 들어 블로그 포스트를 관리하는 시스템이 있다고 하면:

1. 자원(URL): 블로그 포스트는 자원이다. 그 자원의 URL은 /posts처럼 쓸 수 있다.
2. HTTP 메서드:
   • GET: /posts로 요청을 보내면, 모든 포스트를 가져온다. (읽기)
   • POST: 새로운 포스트를 만들 때 /posts로 POST 요청을 보낸다. (생성)
   • PUT: 특정 포스트를 업데이트할 때 /posts/1로 PUT 요청을 보낸다. (수정)
   • DELETE: 특정 포스트를 삭제할 때 /posts/1로 DELETE 요청을 보낸다. (삭제)

이렇게 URL로 자원을 구분하고, HTTP 메서드로 작업을 정하는 방식이 RESTful이다.

 

 

장점

1. 간결하고 직관적인 구조: RESTful API는 URL을 통해 자원을 식별하고, HTTP 메서드(GET, POST, PUT, DELETE 등)로 자원에 대한 작업을 정의하기 때문에 이해하기 쉽고 직관적이다. 개발자들이 쉽게 읽고 사용할 수 있어 유지보수가 용이하다.
2. 언어와 플랫폼에 독립적: RESTful API는 HTTP 프로토콜 위에서 동작하기 때문에, 클라이언트와 서버가 서로 다른 언어 또는 플랫폼을 사용해도 문제가 없다. 웹에서 거의 모든 환경에서 동일하게 동작할 수 있다.
3. 확장성: RESTful API는 서버 측에서 상태를 저장하지 않기 때문에(stateless), 확장성이 뛰어나다. 요청 간에 서버가 클라이언트의 상태를 기억할 필요가 없으므로 서버를 여러 대로 분산하여 처리하기가 쉽다.
4. 캐싱 가능: HTTP 프로토콜의 캐시 기능을 활용할 수 있어, GET 요청에 대한 응답은 클라이언트나 중간 캐시 서버에 저장될 수 있다. 이를 통해 불필요한 서버 요청을 줄이고 성능을 높일 수 있다.
5. 광범위한 도구 지원: REST는 매우 널리 사용되는 표준이기 때문에, 이를 지원하는 다양한 도구와 라이브러리가 존재한다. 이 덕분에 개발과 디버깅이 편리하다.
6. 분리된 클라이언트-서버 아키텍처: RESTful은 클라이언트와 서버의 역할을 명확히 분리한다. 클라이언트는 데이터를 요청하고 서버는 데이터를 제공하는 역할을 명확히 나누기 때문에 시스템이 유연해진다. 클라이언트와 서버가 독립적으로 확장되거나 수정될 수 있다.

정리하자면, RESTful API는 확장성과 단순성, 플랫폼 독립성을 제공하는 동시에 HTTP 기반의 캐싱과 도구 지원 등으로 성능 향상과 개발 편의성을 제공한다. 물론, 특정 복잡한 통신 구조에서는 REST가 한계가 있을 수 있지만, 일반적인 웹 애플리케이션에서는 그 장점이 돋보인다.

 

 

 

단점

1. Point-to-Point 통신: RESTful API는 기본적으로 서버와 클라이언트 간의 단방향 통신을 지원한다. 즉, Point-to-Point 방식의 통신이므로, 이벤트 기반의 실시간 상호작용이나 비동기적 다중 클라이언트와의 복잡한 상호작용을 처리하는 데는 적합하지 않다. 이로 인해 서버-클라이언트 외에 다른 컴포넌트들이 필요한 복잡한 애플리케이션에서는 한계가 있을 수 있다.
2. HTTP 기반 아키텍처의 한계: RESTful API는 HTTP 프로토콜 위에서 동작하기 때문에, HTTP가 제공하는 메커니즘에만 의존해야 한다. 이는 통신이나 보안 정책을 직접 설계하고 구현해야 한다는 부담을 주며, HTTP 외의 특화된 전송 프로토콜을 사용할 수 없다는 한계가 있다.
3. 정확한 설계 필요: RESTful API는 별도의 표준이 없어 설계에 대한 책임이 개발자에게 있다. 이를 잘못 설계할 경우 확장성이나 유지보수성이 떨어질 수 있으며, 여러 가지 비표준적인 구현이 발생할 수 있다.
4. CRUD 메서드 제한: RESTful API는 기본적으로 4가지 메서드(CRUD: Create, Read, Update, Delete)만을 제공한다. 복잡한 비즈니스 로직이나 다단계 작업을 처리하는 데에는 이 메서드만으로는 부족할 수 있다. 이를 보완하려면 추가적인 설계나 구현이 필요하다.
5. 서버 상태 비저장(stateless): REST의 설계 원칙 중 하나는 서버가 클라이언트의 상태를 기억하지 않는다는 것이다. 이를 stateless 아키텍처라고 부르는데, 이로 인해 모든 요청에 필요한 정보를 매번 클라이언트가 보내야 한다. 큰 규모의 요청이나 상태가 중요한 애플리케이션에서는 비효율적일 수 있다.
6. 오버헤드 발생: REST는 텍스트 기반의 JSON이나 XML을 주로 사용하여 데이터를 주고받기 때문에, 바이너리 형식의 프로토콜에 비해 오버헤드가 크고, 처리 속도가 느릴 수 있다.

이런 단점들은 특정한 상황에서 RESTful API의 적합성을 낮출 수 있지만, 대부분의 일반적인 웹 애플리케이션에서는 여전히 많이 사용되는 방식이다.

 

 

 

---

참고한 사이트

[네트워크] REST API란? REST, RESTful이란?

 

[API/서버/백앤드]REST API vs RESTful API 비슷해보이는데 뭐가 달라??(파이썬,스위프트,코틀린 사용 예