Rest API란?

안녕하세요. 오늘은 Rest API에 대해 정리하는 포스팅을 진행해보겠습니다.

 

저희가 흔히 Web Service/Web Application이라 하는 것은 정확히 무엇을 뜻할까요?

 

Web Service란?

네트워크 상에서 서로 다른 컴퓨터들 간에 상호 작용을 위한 소프트웨어 시스템

 

네트워크 상에서 디바이스로부터 WWW(Word Wide Web)을 통해 다른 디바이스로 제공되는 서비스를 말합니다.

이러한 Web Service는 네트워크 상의 통신을 허용해야 하며, 플랫폼에 종속적이면 안됩니다. 또한 기기간 연동을 위한 설계가 되어야 합니다.

 

Web Application이란?

remote server에 저장되어 있고, web browser를 통해 작동하는 application입니다.

web application을 실행해주는 서버를 web application server라 하며, 이는 데이터베이스와의 통신 역할도 합니다.

 

Client로부터 서버로 오는 요청, 그리고 Web Server/ Web Application Server는 그 요청에 대한 작업을 처리한 뒤, 반환을 보내줍니다. 이를 상호 작용이라고 합니다.

 

따라서 Web Server/ Web Application Server를 Design 할 때 Client로부터 오는 요청(Request)과 그에 대한 적절한 형태의 반환(Response)을 설계 해 주어야 합니다. 이 설계 방식 중 SOAP와 REST에 대해 알아보겠습니다.

 

1. SOAP (Simple Object Access Protocol)

저희가 흔히 사용하는 http protocol, 혹은 SMTP와 같은 프로토콜을 이용해서 XML 기반의 메시지를 컴퓨터 네트워크 상에 전달하는 protocol을 말합니다.

 

SOAP은 XML 기반의 메시지를 전달하는 프로토콜입니다. XML 기반은 몇 가지 문제점이 있습니다.

 

1. 간단한 데이터도 많은 양의 데이터로 감싸서 보내야 합니다 (overhead가 높습니다) 따라서 속도도 느려집니다.

2. 개발하기 어렵습니다. (XML 데이터는 json에 비해 가독성면이나 작성하는 사람 입장에서도 어렵습니다.)

 

2. REST (REpresentational State Transfer)

resource의 representation에 의한 상태 전달, HTTP 메서드를 통해 resource를 처리하기 위한 아키텍처입니다.

자원을 이름(representation)으로 구분하여 해당 자원의 상태(status)를 주고 받는 모든 것을 의미합니다.

REST 역시 SOAP와 같이 네트워크 상의 클라이언트-서버 간의 데이터 통신 방식 중 하나입니다.

 

자원을 이름으로 표현한 다는 것은 무엇을 의미할까요?

다른 디바이스로부터 현재 서버가 있는 디바이스로 자원을 요청할 때 특정 URI(Uniform Resource Identifier)를 활용하여

자원에 대한 요청을 받는 것을 말합니다.

 

또한 상태라는 것은 컴퓨터가 가지고 있는 자원(resource)의 상태를 말합니다. 서버의 데이터, 혹은 데이터베이스의 데이터와 같은 모든 자원의 상태를 말합니다.

 

이러한 자원(resource)에 대한 요청을 URI로 받고, 처리한 뒤(http method를 따라서), 자원(resource)의 상태를 Transfer(전달)하는 방식이 REST 방식입니다. 

 

 

REST는 http 프로토콜을 이용해서 구현합니다. 

http protocol은 크게 http method와 http status로 구분할 수 있습니다. 

 

http method라는 것은 클라이언트가 서버에 요청을 보낼 때 어떠한 종류의 요청인가를 말해주는 방식입니다. (GET, POST, PUT, DELETE ...)와 같은 메서드가 있습니다.

 

서버가 요청을 처리한 뒤, http status code를 반환해 주어 처리에 대한 상태를 보여줍니다. 예를 들어 200번대 http status가 반환되면, 정상적으로 작동했다를 알 수 있고, 400번대가 반환되면 무언가 잘못된 요청이 들어왔음을 알 수 있습니다.

 

REST API란 이러한 REST service를 제공하는 API(Application programming interface)를 말합니다. 이러한 REST API를 제공하는 웹 서비스를 RESTful Web Service라고 말합니다.

 

3. RESTful service의 특징

그러면 마지막으로 RESTful service의 특징에 대해 알아보겠습니다.

 

1. 장점과 단점

• 장점.
• REST는 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 별도의 인프라 구축이 필요하지 않습니다.
• http 프로토콜을 사용하는 모든 디바이스 위에서 작동합니다. 즉 Web에서 작동하는 REST API는 같은 방식으로 모바일 애플리케이션에서 오는 요청에 대해서도 작동합니다.
• 메시지가 자원에 대한 URI와 http method로 이루어져 있기 때문에 명시적으로 의도하는 바를 파악할 수 있습니다.
• 단점.
• http 프로토콜 위에서 작동하기 때문에 http 프로토콜의 단점을 이어 받습니다. 메서드가 한정적이고, 적습니다.

하지만 위 장점 중 2번 cross platform에서의 요청 처리가 매우 중요하기 때문에 현재 REST 방식은 대부분의 웹 서비스에서 사용되고 있습니다.

 

2. Uniform Interface

아까 REST는 자원에 대한 URI를 독립적으로 갖는다고 하였습니다. 따라서 모든 resource에 대한 요청은 정해진 URI를 통해서만 이루어져야 합니다. 또한, 이러한 URI는 플랫폼에 독립적이기 때문에 외부 HTML이 변경되거나 심지어 HTTP에 대한 명세가 변경되어도 자원에 대한 URI는 변하지 않습니다.

 

3. Stateless

Http protocol이 stateless하다라는 말씀을 어디선가 들어보신 분들이 계실 수도 있습니다. 이는 통신을 서로 주고받아도 클라이언트와 서버가 서로 연결되어 있지 않기 때문에 통신이 독립적으로 수행됨을 의미합니다.

 

만약에 http request가 두번 연속으로 발생하더라도, 2번째 request가 처리되는 시점에 1번째 request에 대한 정보는 가지고 있지 않습니다.

 

이렇게 되면, 각 요청에 대한 반환만 독립적으로 설계하면 되기 때문에 서버 디자인이 단순해지는 효과를 얻습니다. REST는 http 프로토콜 위에서 작동하기 때문에 이 stateless라는 특징을 그대로 이어받습니다.

 

4. Cacheable

http 프로토콜은 기본적으로 캐싱이 가능합니다. 캐싱이 가능하다는 의미는 기존에 변경되지 않은 자원들은 저장해놓은 자원을 그대로 사용하고, 변경된 자원들에 한에서 데이터 변경이 이루어집니다. 기존의 자원을 사용한다는 것은 네트워크 통신을 줄이기 때문에 UX 향상에 도움을 줍니다. HTTP 메서드 중 GET에 한정되어있으며 `Cache-Control:max-age=100`이런 식으로 한정된 시간을 정할 수가 있으며 이 캐싱된 자원이 유효한지를 판단하기 위해 `Last-modifed` 그리고 `Etag`를 씁니다.

 

5. Layered System

계층화된 구조로 아키텍쳐를 디자인할 수 있습니다. ~/a/b/c/d/~의 방식으로 언제든 서버 디자인하는 개발자가 원하는 계층구조 처리를 진행할 수 있습니다.

 

6. Client-Server 구조

resource에 대한 자원이 있는 쪽이 Server, 요청하는 쪽이 Client가 됩니다.

Client-Server는 각각 독립적인 구조를 가져야 합니다. 즉 Server는 API를 제공하고 적절한 비즈니스 로직을 처리하면 됩니다. Client 역시 받은 자원에 대한 처리 로직만 정확하게 구현하면 됩니다. 이는 서로 간의 의존성을 줄여주는 효과를 갖습니다.

 

오늘은 이렇게 REST API란 무엇인가, 그리고 REST API의 특징에 대해 알아보았습니다.

 

*저의 글에 대한 피드백이나 지적은 언제나 환영합니다.