웹 개발의 기본인 REST API에 대해서 알아보자.
참고자료:
REST API란?
RESTful API란 무엇입니까? [AWS]

REST API란?

RESTful API는 Respresentational State Transfer의 약자로, 웹 기반의 분산 시스템에서 자원을 표현하고 상태를 전달하기 위한 아키텍처 스타일이다. RESTful API는 일반적으로 HTTP 프로토콜을 기반으로 구현되며, 클라이언트와 서버 간의 통신을 위한 표준화된 방법을 제공한다.

RESTful API의 주요 개념 & 특징

1. 자원(Resource): API에서 제공하는 모든 것을 자원으로 간주한다. 예를 들어, 사용자, 제품, 주문과 같은 개별 개체가 자원이 될 수 있다. 각 자원은 고유한 식별자(URI)를 가지고 있다.

2. 표현(Representation): 자원은 서버와 클라이언트 사이에서 주고받는 데이터의 표현이다. JSON XML, HTML 등의 형식으로 표현될 수 있으며, 클라이언트는 이를 이해하고 처리할 수 있어야 한다.

3. 상태 전달(State Transfer): 클라이언트와 서버 간의 통신은 상태 전달을 통해 이루어진다. 클라이언트는 요청을 보내고, 서버는 요청에 대한 적절한 응답을 제공한다. 이때 상태 전달은 HTTP 메서드를 사용하여 수행된다.

4. HTTP 메서드 활용: RESTful API에서는 HTTP 메서드를 활용하여 자원에 대한 동작을 표현한다. 가장 일반적으로 사용되는 메서드는 다음과 같다.

• GET: 자원을 조회하거나 가져온다.

• POST: 자원을 생성한다.

• PUT: 자원을 수정한다.

• DELETE: 자원을 삭제한다.

5. URI(Uniform Resource Identifier): 자원을 식별하기 위해 고유한 URI를 사용한다. 예를 들어 "/users", "/products/123" 과 같은 URI를 통해 자원에 접근한다.

6. Stateless(무상태성): RESTful API는 서버가 클라이언트의 상태를 유지하지 않는다. 각 요청은 클라이언트의 필요한 정보를 포함하고 있으며, 서버는 이를 기반으로 처리하여 응답한다.

GET과 POST의 차이점

간단하게 GET은 데이터를 가져오기 위해 사용되고, POST는 데이터를 생성하기 위해 사용된다.
GET은 요청 시 데이터를 URL 매개변수로 전달하며, POST는 요청 본문(body)에 데이터를 담아 전송한다.

목적

• GET: 리소스의 표시나 조회를 위해 사용된다. 서버에서 데이터를 가져와 클라이언트에게 보여준다.

• POST: 리소스를 생성하거나 서버에 데이터를 제출하기 위해 사용된다. 클라이언트가 서버에 데이터를 전송하고, 서버는 해당 데이터를 처리하여 새로운 리소스를 생성한다.

데이터 전달 방식

• GET: 데이터를 URL의 쿼리 매개변수에 포함하여 전달한다. 데이터가 URL 에 노출되므로 보안에 취약할 수 있다.

• POST: 데이터를 요청의 본문에 포함하여 전달한다. 데이터가 URL 에 노출되지 않으므로 보안적으로 안전하다.

데이터 길이

• GET: 전송할 수 있는 데이터의 길이에 제한이 있으며, 일반적으로 몇 백자까지 제한된다.

• POST: 전송할 수 있는 데이터의 길이에 제한이 없다. 더 많은 데이터를 전송할 수 있다.

캐싱

• GET: 응답이 캐시될 수 있다. 동일한 GET 요청에 대한 응답은 캐시에서 가져올 수 있으며, 반복 요청 시 네트워크 부하를 줄일 수 있다.

• POST: 응답은 캐시되지 않는다. POST 요청은 매번 새로운 데이터를 서버로 전송하므로 응답이 캐시되지 않는다.

RESTful API를 사용하는 이유

대표적인 이유는 HTTP 프로토콜이다.

REST API는 HTTP 프로토콜 인프라를 그대로 사용하기 때문에, HTTP를 따르는 모든 플랫폼에서 사용이 가능하다. 즉, 웹의 장점을 최대한 살릴 수 있는 아키텍처 스타일이다.

또한 HTTP의 특징과 같이 요청에 대한 것을 명확하게 밝히기 때문에 의도를 파악하기 쉽고 서버와 클라이언트의 역할을 명확히 나눌 수 있다.

REST 6가지 원칙

1. 균일한 인터페이스

   • 서버가 표준 형식으로 정보를 전송한다.

   • 요청은 리소스를 식별해야 하기 때문에 균일한 리소스 식별자를 사용해야한다.

   • 서버는 클라이언트가 리소스를 적절하게 사용할 수 있는 방법에 대한 메타데이터가 포함된 명확한 메시지를 전송한다.

2. Stateless(무상태)

   • 서버가 이전의 모든 요청과는 독립적으로 모든 클라이언트 요청을 완료하는 통신 방법, 클라이언트는 임의의 순서로 리소스를 요청할 수 있으며, 모든 요청은 무상태이거나 다른 요청과 분리된다.

   • HTTP 프로토콜을 따르기 때문에 HTTP 특징과 같이 상태를 저장하지 않으며, 요청에 모든 정보가 담겨 한 번에 전송해야 한다.

3. Layered System(계층화 시스템)

   • 아키텍처에서 클라이언트는 클라이언트와 서버 사이의 다른 승인된 중계자에게 연결할 수 있으며, 여전히 서버로부터도 응답을 받는다.

   • 서버는 요청을 다른 서버로 전달할 수 있으며, 클라이언트 요청을 이행하기 위해 함께 작동하는 보안, 어플리케이션 및 비즈니스 로직과 같은 여러 계층으로 여러 서버에서 실행되도록 REST 웹 서비스를 설계할 수 있다. 이러한 계층은 클라이언트에는 보이지 않는 상태로 유지된다.

4. Caching(캐시 가능성)

   • 서버 응답 시간을 개선하기 위해 클라이언트 또는 중계자에 일부 응답을 저장하는 프로세스인 캐싱을 지원한다.

5. Client-Server

   • 클라이언트와 서버는 반드시 분리되어야 하며, 클라이언트는 데이터를 서버에 요청하고 서버는 클라이언트의 요청에 따른 데이터를 응답해야 한다.

6. Code on demand

   • 서버는 소프트웨어 프로그래밍 코드를 클라이언트에 전송하여 클라이언트 기능을 일시적으로 확정하거나 사용자 지정할 수 있다.

RESTful하게 디자인한다는 것의 의미

1. 리소스와 행위를 명시적이고 직관적으로 분리한다.

   • 리소스는 URL로 표현되는데 리소스가 가리키는 것은 명사로 표시되어야 한다.

   • 행위는 HTTP Method로 표현하고, GET, POST, PUT, PATCH, DELETE를 분명한 목적으로 사용한다.

2. Message는 Header와 body를 명확하게 분리해서 사용한다.

   • Entity에 대한 내용은 body에 담는다.

   • 어플리케이션 서버가 행동할 판단의 근거가 되는 컨트롤 정보인 API 버전 정보, 응답 받고자 하는 MIME타입 등은 header에 담는다.

   • header와 body는 http header와 http body로 나눌 수 있고, http body에 들어가는 json구조로 분리할 수 있다.

3. API 버전을 관리한다.

   • 환경은 항상 변하기 때문에 API의 signature가 변경될 수 있음에 유의하자.

   • 특정 API를 변경할 때는 반드시 하위호환성을 보장해야 한다.

4. 서버와 클라이언트가 같은 방식을 사용해서 요청하도록 한다.

   • 브라우저는 form-data 형식으로 submit을 보내고 서버에서는 json형태로 보내는 식의 분리보다는 json으로 보내든, 둘 다 같은 형식으로 통일한다.

   • 다른 말로 표현하자면 URI가 플랫폼 중립적이어야 한다.

RESTful API의 장점

1. 확장성
   • REST가 클라이언트-서버 상호 작용을 최적화하기 때문에 효율적으로 크기를 조정할 수 있다. 통신 병목 현상을 일으키지 않으면서 확장성을 지원한다.
2. 유연성
   • 완전한 클라이언트-서버 분리를 지원하기 때문에 각 부분이 독립적으로 발전할 수 있도록 다양한 서버 구성 요소를 단순화하고 분리한다. 예를 들어 서버의 기술 변경이 클라이언트에 영향을 주지 않는 경우 등
3. 독립성
   • REST API는 사용되는 기술과 독립적이다. API 설계에 영향을 주지 않고 다양한 프로그래밍 언어로 클라이언트 및 서버 모두 작성할 수 있다.

• REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다.

• Hypermedia API의 기본을 충실히 지키면서 사용이 가능하다.

• 여러 가지 서비스 디자인에서 생길 수 있는 문제를 최소화한다.

• 서버와 클라이언트의 역할을 명확하게 분리한다.

• HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용 가능하다.

• HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해준다.

• HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구축할 필요가 없다.

RESTful API의 단점

• 사용할 수 있는 Method가 한정적이다.

• 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 정보의 값을 처리해야 하므로 전문성이 요구된다.

• 분산환경에는 부적합하다.

• HTTP 통신 모델에 대해서만 지원한다.