네트워크 - REST API, RESTful

REST(Representational State Transfer) API

---

REST API는 HTTP 요청을 사용하여 데이터에 접근하고 이를 사용 또는 인터넷을 통해 안전하게 교환하는 API 아키텍처이다. 즉, REST API는 두 컴퓨터 시스템이 통신하는 방법이라고 생각해 볼 수 있다.

REST는 인터넷과 같은 복잡한 네트워크에서 통신을 관리하기 위한 지침으로 만들어졌는데 이를 기반으로 대규모의 고성능 통신을 안정적으로 지원할 수 있게 되었다.

 

• API(Application Programming Interface)

API는 다른 소프트웨어 시스템과 통신하기 위해 따라야 하는 규칙을 정의한 것이다.

 

REST 설계 원칙

• 균일한 인터페이스

동일한 리소스에 대한 모든 API 요청은 요청의 출처와 관계 없이 동일하게 표시되어야 한다. 리소스는 너무 커서는 안 되며 클라이언트가 필요로 할 수 있는 모든 정보를 포함할 수 있어야 한다.

또한 사용자의 이름 또는 이메일 주소와 같은 동일한 데이터가 하나의 URI에만 속하도록 해야 한다.

• 클라이언트-서버 분리

클라이언트 및 서버 애플리케이션은 서로 완전히 독립적이어야 한다.

클라이언트에서 알아야 하는 유일한 정보는 요청된 리소스의 URI로 해당 방법 외에는 서버와 통신할 수 없다.

서버 또한 HTTP를 통해 요청된 데이터를 클라이언트로 전달하는 것 외에는 클라이언트를 수정해서는 안 된다.

• 무상태

무상태이기 때문에 각 요청에는 처리에 필요한 모든 정보가 포함되어야 한다. 즉, 서버 측 세션이 필요하지 않다는 의미이고 서버에서는 클라이언트 요청과 관련된 데이터를 저장할 수 없다.

• 캐시 가능성

가능한 경우 클라이언트나 서버 측에서 리소스를 캐시할 수 있어야 한다. 서버 응답에는 전달된 리스소에 대해 캐싱이 허용되는지 여부에 대한 정보도 포함되어야 한다.

목표는 클라이언트 측의 성능을 향상시키는 동시에 서버 측의 확장성을 높이는 것이다.

• 계층화된 시스템 아키텍처

호출과 응답이 서로 다른 계층을 거친다.

일반적으로 클라이언트와 서버가 서로 직접 연결된다고 가정하지 않는다.

통신을 담당하는 중개자를 두고 클라이언트나 서버가 최종 애플리케이션과 통신하는지 중개자와 통신하는지 알 수 없도록 설계해야 한다.

• 코드 온디맨드

일반적으로 정적 리소스를 전송하지만 경우에 따라 응답에 실행 코드가 포함될 수 있는데 이럴 경우 코드는 온디맨드 방식으로만 실행되어야 한다.

 

RESTful API

---

RESTful API는 두 컴퓨터 시스템이 인터넷을 통해 정보를 안전하게 교환하기 위해 사용하는 인터페이스이다.

앞에서 살펴봤던 REST와 간단히 비교해보자면 REST는 아키텍처 스타일이고 RESTful은 이러한 스타일을 구현한 웹 서비스를 말한다.

 

RESTful API 주요 구성요소 

• 헤더

HTTP 헤더의 도움으로 RESTful API는 요청 메시지와 유효한 응답에 대한 연결 유형, 프록시, 메타데이터와 같은 정보를 관리한다.

• 데이터

데이터는 클라이언트가 요청한 리소스에 대한 추가 정보를 포함하는 본문으로 클라이언트가 헤더에서 콘텐츠 유형을 결정할 때 본문에는 실제 콘텐츠가 포함된다.

• 메서드

GET, POST, PUT, DELETE와 같은 특정 HTTP 메서드를 사용하여 데이터를 조작할 수 있다.

• 대표적인 HTTP 메서드

메서드 종류	설명
GET	- 서버의 리소스를 조회할 수 있는 메서드이다. 데이터를 보낼 수도 있는데 그 때는 쿼리스트링을 이용해서 보내게 된다. - POST도 조회 용도로 사용할 수 있지만 GET을 사용하는 이유는 캐싱이 가능하기 때문이다.
POST	- HTTP 메시지 바디를 통해 서버로 요청 데이터를 전송한다. - 이전에 살펴봤던 GET 메서드도 쿼리스트링을 통해서 데이터를 서버로 전송할 수 있지만, 중요한 정보는 노출되면 안되기 때문에 POST를 통해서 메시지 바디를 이용하는 것이 더 좋다.
PUT	- 리소스를 대체하는 메서드로 요청 메시지에 리소스가 있다면 덮어쓰고, 없으면 새로 생성한다. - 비슷한 기능을 하는 PATCH와 비교해보자면 PUT은 덮어쓰면서 전체를 변경하지만, PATCH는 일부분만 수정한다는 차이가 있다.
PATCH	- 리소스 일부를 변경하는 메서드로 이전의 PUT 메서드와 비슷한 기능을 한다. - 만일 PATCH를 지원하지 않는 서버에서는 POST를 대신 사용하는 방법도 있다.
DELETE	- 리소스를 제거하는 메서드이다.

 

• 엔드포인트

서버에서 데이터 위치를 정의하는 URL로 기본적으로 API를 통해 액세스하려는 리소스이다.

 

RESTful API의 이점

• 확장성

REST API를 구현하는 것이므로 클라이언트-서버 상호 작용을 최적화하기 때문에 효율적으로 크기를 조정할 수 있다.

• 유연성

RESTful API 웹 서비스는 완전한 클라이언트-서버 분리를 지원한다. 이를 통해서 각 부분이 독립적으로 발전할 수 있도록 다양한 서버 구성 요소를 단순화하고 분리할 수 있다.

서버의 플랫폼 또는 기술이 변경되어도 클라이언트에 영향을 주지 않는다.

• 독립성

API 설계에 영향을 주지 않고 다양한 프로그래밍 언어로 클라이언트 및 서버를 모두 작성할 수 있다. 또한 통신에 영향을 주지 않고 양쪽의 기본 기술을 변경할 수 있다.

 

참고 자료

---

REST vs RESTful APIs: Comparing APIs from a Developer’s Perspective

RESTful API란 무엇인가요? - RESTful API 설명 - AWS

REST API란 무엇인가요? | IBM