[HTTP] API, REST

API, 그리고 REST에 대해 알아보자.

____________________________________________________________________________________

1. API (Application Programming Interface)

한 *애플리케이션에서, 다른 애플리케이션과 상호 작용(통신)하기 위한 방법이다.

 

운영체제, 데이터베이스, 객체 지향 파일 등 광범위한 데이터에 대하여 API를 생성할 수 있고, 이렇게 만들어진 도구와 기능들을 애플리케이션 간에 제공하고 통신할 수 있도록 도와주는 것이 API의 역할이다. 개발자는 본인이 원하는 기능을 구현하기 위해 굳이 복잡할 코드를 직접 입력할 필요 없이, 다른 애플리케이션에 API를 요청함으로써 애플리케이션을 더욱 쉽고 효율적으로 개발할 수 있다.

※ 애플리케이션(Application): 고유한 기능을 가진 모든 소프트웨어 시스템

 

사진 출처 : https://planningpokerweb.com/product-management/apis-the-unseen-bridge-in-digital-products-for-non-tech-people/

 

구글링을 통해 외국 문서들을 읽다보면, API를 '레스토랑의 웨이터'에 비유를 하는 경우가 많다.

 

어떤 손님이 레스토랑에 방문했다고 가정하자. 주문을 할 때, 손님이 레스토랑 주방에 들어가서 직접 셰프에게 음식을 주문하는 경우는 정말 드물다. 손님은 레스토랑의 웨이터를 통해서 '메뉴를 주문'하고, 웨이터는 셰프에게 '주문을 전달'한다. 음식이 완료되면 셰프는 웨이터에게 '음식을 전달'하고, 웨이터는 다시 손님에게 주문에 맞는 '음식을 전달'한다.

 

바로 이 웨이터의 역할이 API의 그것과 같다.

 

클라이언트(손님)의 요청(메뉴 주문)을 서버(셰프)에 전달하고, 서버는 그 요청에 걸맞는 적절한 응답(음식 전달)을 다시 클라이언트에게 돌려주는... 결국, API는 클라이언트와 서버가 *리소스를 주고 받기 위한 매개체라고 할 수 있다.

※ 리소스(Resource): 애플리케이션이 클라이언트에게 제공하는 데이터 (텍스트, 이미지, JSON, XML 등)

____________________________________________________________________________________

2. REST (REpresentational State Trasnfer)

사진 출처 : https://medium.com/codestorm/best-practices-for-rest-api-development-8434352f3213

 

REST는 서버와 클라이언트의 통신 방식 중 하나로, HTTP 프로토콜을 기반으로 리소스를 표현하고 조작하여 웹 애플리케이션을 설계하기 위한 일련의 원칙을 정의하는 아키텍쳐 스타일이다. 한 마디로, 서버와 클라이언트가 데이터를 주고받기 위해 필요한 API의 작동 방식에 조건을 부과하는 방법이라고 이해하면 쉽다. 

 

REST에서 가장 중요한 개념은 리소스의 상태 표현(Represent)과 리소스의 전달(Transfer)이다.

_

1) 리소스의 상태 표현

리소스를 구분하는 방법을 의미한다. 웹 상에서 존재하는 모든 리소스는 고유한 식별자인 HTTP URI를 통해 식별된다. 클라이언트는 GET, POST, PUT, DELETE와 같은 표준 HTTP Method를 사용하여 서버가 제공하는 리소스와 상호작용하는데, 그 과정에서 서버는 명시된 식별자를 통해 리소스의 위치를 파악하여 내부 로직을 수행할 수 있다. 식별된 리소스를 통해 일관된 인터페이스를 구현하고, 애플리케이션의 다양한 기능을 구현할 수 있는 것이다.

_

2) 리소스의 (간접적인) 전달

클라이언트와 서버가 서로 리소스를 주고받을 때, 리소스를 raw한 상태가 아닌, HTTP Message에 리소스를 포함한 보내고자 하는 모든 정보를 담아서 전달한다. 클라이언트는 HTTP Method를 지정하여 리소스를 처리하는 방식을 지정하고, 서버는 해당 요청에 걸맞는 CRUD(Create, Read, Update, Delete)와 추가적인 작업을 수행하고, 서버의 내부 로직 수행이 종료되면 다시 응답을 돌려준다. 이 과정에서 서버와 클라이언트는 리소스를 직접적으로 주고받지 않고, 리소스와 관련된 모든 내용을 HTTP Message를 통해 간접적으로 주고받음으로써, 서버와 클라이언트의 결합도를 낮추고, 각각 독립적으로 확장이 가능하다.

____________________________________________________________________________________

2-1. REST의 특징?

1) 인터페이스의 일관성

REST는 클라이언트와 서버가 준수해야 하는 일련의 제약 조건을 정의하고, 리소스의 조작 방법을 통일화하여 다양한 플랫폼에서 한정적인 방법으로 API를 다룰 수 있게 한다.  HTTP 프로토콜을 기반으로 한 REST는 (위에서 언급했듯이) 표준화된 HTTP Method, HTTP URI, 그리고 이를 포함한 HTTP Message를 통해 서버와 클라이언트가 리소스를 조작하고 상호작용할 수 있도록 균일한(Uniform) 규칙을 제공하여 웹 애플리케이션의 확장성, 그리고 유지보수의 용이성을 보장한다.

_

2) 상태 비저장 통신 (Stateless)

HTTP의 대표적인 특징 중 하나인 Stateless는 REST의 특징에도 적용된다. RESTful 애플리케이션에서 서버는 클라이언트의 상태에 대한 어떠한 정보도 저장하지 않고, 클라이언트는 (설령 동일한 요청이라 할지라도) 모든 요청을 서버에게 새롭게 독립적으로 전달해야 한다. 서버는 클라이언트의 Context(세션, 쿠키 등)를 전혀 저장하지 않으므로, 복잡한 세션 관리 없이 단순화하여 클라이언트의 즉각적이거나 대용량의 요청에도 유연하게 리소스를 할당하여 쉽게 애플리케이션을 확장할 수 있다.

 

무엇보다도, 서버에 장애가 발생한 경우 서버 측에서 상태의 손실 없이 클라이언트의 요청 처리를 재개할 수 있다는 큰 장점을 가지고 있다. 단순히 클라이언트가 요청을 재전송하면, 서버가 이를 새로운 요청으로 처리하기 때문이다. 만약 클라이언트의 상태를 지속적으로 저장하는 Stateful한 애플리케이션이었다면, 통신 과정 중 서버 장애가 발생하면 클라이언트는 요청의 처음 과정부터 다시 진행해야 할 것이다. 애플리케이션의 안정성을 향상시키고, 결함이 발생할 확률을 낮추는 중요한 특징이다.

_

3) 캐시 가능성(Cacheable)

HTTP 프로토콜을 기반으로 하는 REST는 캐싱을 강조한다. 서버는 HTTP Response Message에 캐시 헤더를 지정하여 캐싱 가능 여부와 기간을 표시할 수 있고, 클라이언트는 (캐싱이 허락된) 해당 응답을 임시로 저장하고, 그 저장된 응답을 후속 요청에 동일하게 사용하여, 서버의 부하를 줄이고 대용량의 요청/응답에도 효율적이고 빠르게 대응할 수 있다.

_

4) 계층화된 시스템 (Layered System)

서버와 클라이언트 사이에 방화벽, 게이트웨이, 프록시, 로드 밸런싱, 암호화, 보안 등 다양한 형태의 서버 구성 요소를 추가하여 유연한 애플리케이션을 만들 수 있고, 각 계층이 특정한 책임을 맡게 되면서 독립적으로 개발/확장을 할 수 있다.

_

5) 독립된 클라이언트와 서버

클라이언트와 서버의 관심사가 명확하게 분리된다.  클라이언트는 요청을 통해 서버의 리소스를 소비하고, 서버는 요청에 대한 응답을 반환함으로써, 클라이언트와 서버가 각자 독립적인 역할과 책임을 지니고 있다. 클라이언트는 서버의 내부 로직을 알 필요가 전혀 없으며, 서버 역시 클라이언트의 요청을 제외한 나머지 사항을 알 필요가 없다. 이렇듯 REST는 클라이언트와 서버의 결합도를 낮추고 디커플링(De-Coupling)을 유도하여 애플리케이션의 확장성과 유연성을 유지시킨다.

 

또한, 클라이언트와 서버의 느슨한 결합은, 서버 측에서 장애가 발생하여도 클라이언트에 영향을 주지 않고(=애플리케이션을 중지하지 않아도) 서버를 교체하거나, 대체 서버로 전환하는 매커니즘을 쉽게 구현할 수 있어서, 애플리케이션의 보안성과 안전성을 향상시키는 장점을 가지고 있다.

____________________________________________________________________________________

 

지금까지 REST에 대하여 알아보았다. REST는 Stateless, Cacheable 등 HTTP 프로토콜의 특징과 상당히 겹치는 부분이 많고, REST를 구현하기 위해서는 HTTP 프로토콜에 상당히 의존적이라는 것을 알 수 있다. 확실히 REST는 HTTP 프로토콜을 기반으로 설계된 개념임을 확인할 수 있는데, 이를 통해 REST를 제대로 구현한, 즉 RESTful한 애플리케이션은 웹의 장점을 최대한으로 활용하여 다양한 플랫폼에서, 대규모의 고성능 통신을 안정적으로 지원할 수 있다.

 

다만, REST는 정확한 표준이 없고, 애플리케이션이 웹 상의 리소스를 효율적으로 활용하기 위해 정해놓은 '암묵적인 규칙'이다. 한 마디로, 마땅한 정의가 존재하지 않는 REST는 이를 구현하는 개발자에 따라 다르게 해석될 수 있는 여지가 다분하다는 뜻이다. 따라서, 개발자는 애플리케이션의 특징, 개발 환경, 요구 사항 등 다양한 변수와 상황을 모두 고려하여 애플리케이션을 설계해야한다.

 

무엇보다도, 애플리케이션은 REST를 100% 실현할 수 없다.  REST를 준수하려다가, 되려 REST보다 몇 배 더 중요한 개발 요소(비용, 시간 등)을 놓칠 수 있다. 따라서, 최대한 REST를 준수하여 애플리케이션을 설계하되, 무리는 하지 말자는 뜻이다. 배보다 배꼽이 크거나, 몸보다 머리가 커지는 상황이 발생할 수 있다.

____________________________________________________________________________________