RESTful API란 일반적으로 REST(Representational State Transfer) API를 제공하는 웹 서비스를 일컫는다. RESTful API가 무엇인지 답하기 위해서는, REST의 정의가 핵심이라고 할 수 있다. REST를 가리키는 한국어 표준 단어가 있는지 모르겠지만, 굳이 표현하자면 "표현적 상태 전송" 정도로 볼 수 있을 것 같다. REST는 무엇을 표현하고, 상태는 무엇의 상태를 말하는가?
서버와 클라이언트 사이의 명료한 구분은 블록체인 기술이 등장한 현대시대에 다소 불분명해진 부분이 있지만, 서버는 자원(Resource)을 저장하고, 클라이언트는 요청한다는 구분은 여전히 주효하다고 할 수 있다. 서버가 가지고 있는 자원은 영구하지 않다. 비록 자원을 가리키는 식별자의 이름은 동일하더라도, 그 식별자가 가리키는 변수 내부의 데이터는 의미를 유지하면서도 변화할 수 있다. 가령 올해의 내 카드 사용 내역을 "나의 카드 사용 내역"이라는 변수 내부에 저장하고 있다면, 한 해가 끝나갈수록 데이터는 점차 많아질 수 있다. 때로 신용 거래를 취소해야 할 경우도 있는데, 이때도 데이터는 변화한다. REST는 서버가 저장하고 있는 변수 내부 데이터의 현재 상태(State)를 송, 수신할 것을 전제한다. 데이터의 현재 상태는 데이터 집합의 의미를 대표하는 특정한 식별자로 표현(Representation)된다. 서버와 클라이언트 사이의 데이터 송수신을 말할 때, 이렇듯 표현형에 따른 정보 상태의 전달이라는 관점은 RESTful한 웹 서비스와 그렇자 않은 경우를 구분하는 특별한 기준점이라고 보기 어렵다. RESTful한 웹사이트인지 구분하기 위한 기준은 그 웹서비스가 REST라는 정의에 충족하는지가 아니라, 그것이 포함하고 있는 문제의식을 개발자가 공유하고 있는지와 더 가깝다고 볼 수 있다.
RESTful한 구현이 필요한 이유는 그것이 보다 직관적이고, 또 직관적인 표현(Represenatation)으로 통일함이 필요한 경우가 있기 때문이다. 하나의 서버는 수많은 클라이언트 각각과 상태 전송을 전제한다. 어떤 클라이언트는 나의 웹 서비스를 컴퓨터로 사용할 수 있지만, 다른 클라이언트는 모바일 환경에서 사용할 수도 있고, 둘을 동시에 사용할 수도 있다. 같은 서비스를 멀티 플랫폼으로 제공하는 것을 전제하는 상황에서, 자원의 표현형이나 자원을 다루는 방식의 표현 등 개발 인터페이스를 통일하는 것이 합리적이다. REST는 HTTP Protocol을 기반하고 있으므로, HTTP Protocol을 따르는 모든 플랫폼에서 RESTful한 구현이 가능하다. HTTP Protocol을 따른다는 것은 이외에도 다양한 장점을 RESTful하게 구현했을 때 개발자 등에게 제공하는데, 가령 무상태성(Stateless)을 통해 서버 부하를 감축시킬 수 있다던지, 캐시 데이터 처리가 가능하다던지 하는 것이다. 하지만 이것은 HTTP Protocol을 사용한 웹 서비스 구현에 따른 장점이지, 오롯이 RESTful한 구현에 따른 장점이라고 볼 수 있다. RESTful한 구현은 HTTP Protocol 사용과 더불어, 앞서 말한 통일성에 그 장점이 있다. API를 구현할 때 RESTful한 구현 방식으로 통일하게되면, 하나의 구현 방식을 공유하게 되므로 확장성, 재사용성이 높아지므로 생산성을 높이거나 유지보수를 하기에 보다 용이해진다. 또 그 표현형이 직관적이므로, 다른 언어로 같은 웹 서비스를 구현할 필요가 있을 때에도 편리한 측면이 있다.
그렇다면 어떻게 해야 RESTful한 구현이 가능할까? 어떤 명확한 표준이 존재해서 RESTful한 구현과 그렇지 않은 것을 구분할 수 있는 것은 아니지만, 일반적으로 통용되는 몇 가지 규칙이 존재한다.
서버의 모든 자원은 다른 자원과 구분되는 고유한 ID를 가진다. RESTful한 구현은 클라이언트가 HTTP URI라는 고유한 정보를 가지고 서버 자원에 접근할 것을 전제한다. URI(즉 고유한 식별자)는 담고 있는 Resource를 명확하게 표현해야 한다. 예를 들어 자원 그 자체는 동사보다 명사형 단수 표현이 좋고, 대문자보다 소문자 사용이 지향된다. 그러나 여러 자원을 담고 있는 컬렉션이라면, 복수형 명사 표현이 보다 직관적이다.
자원의 상태는 클라이언트 요청에 따라 달라질 수 있다. 단순히 서버의 자원을 내려받을 것을 요청할 수 있고(GET), 새로운 데이터를 추가하거나(POST), 변경하거나(PUT), 제거할 수 있을 것이다(DELETE). 식별자인 HTTP URI와 클라이언트의 요청은 명확히 구분되어야 한다. URI에 요청과 같은 동사형 표현이 들어가선 RESTful하다고 보기 어렵다.
HTTP method에 따른 클라이언트의 행위(Verb)는 서버로 하여금 적당한 응답을 하게 만든다(Representation of Resources). 이 응답은 JSON일수도 있고, XML일수도 있으며, 그 외의 다른 형태로 표현될 수 있다.
그 외에도 URI는 슬래쉬(/)문자로 끝나지 않아야 한다던지, 밑줄(_)을 URI에 사용해선 안된다던지, 파일 확장자는 URI에 포함해선 안되는 등 몇 가지 규칙이 더 있다.
RESTful API의 예시로 다음과 같은 예가 있다.
출처: https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html
추가. ) 이번 주차에선 Package.json에 대하여 새로 알게되었다. Package.json은 현재 내 서비스에 설치되어 있는 Package와 버전 정보가 담겨 있다. node_modules없이 배포하는 경우 Node Package Manager를 사용해 일괄적으로 의존적인 packages를 install할 수 있지만, Package.json에는 package의 특정 버전이 아닌 버전 범위(Version range)가 저장되므로, package의 특정 버전까지 일치할 필요가 있다면 Package-lock.json을 사용해 install할 필요가 있다.
