REST API
REST API는 컴퓨터 간의 네트워크 통신을 위한 설계 원칙이다.
분명히 해야할 것은 REST API는 프로토콜이 아니라는 것이다.
프로토콜이나 설계 원칙이나 비슷한 개념인 것 같지만 이 둘을 확실히 구별할 수 있어야 REST가 무엇인지 확실히 이해할 수 있다고 생각한다.
프로토콜 vs 설계 원칙
설계 원칙은 프로토콜이 나아가야 할 방향성을 제시해준다.
프로토콜은 정해진 포멧이 존재하지만, 설계 원칙은 규칙이 존재한다.
프로토콜은 정해진 포멧이 존재한다. HTTP는 대표적인 프로토콜로서 클라이언트가 서버에 request를 보내거나 서버가 클라이언트에게 response를 보낼 때 어떤 포멧으로 보내야 하는지 하나하나 명확하게 규정하고있다. 이는 다른 프로토콜도 마찬가지이다.
반면에 설계 원칙(REST API)은 규칙을 통해 해당 기술(HTTP)이 나아가야 할 방향성을 제시해준다. REST API의 내용을 살펴보면 프로토콜에 비해 뭔가 애매모호하다는 느낌을 받는다. 명확한 포멧 없이 RESTful API가 어떤 조건을 충족해야 하고 어떤 방식으로 설계되어야 하는지에 대한 규칙만 존재한다.
REST API와 HTTP
REST API에 대한 자료를 찾아보다 보면 HTTP에 대한 내용이 많을 수밖에 없다. 내가 처음 REST API를 조사할 때 REST API == HTTP라고 착각할 정도였다. 하지만 정확히 말하자면 서로 분야가 다르다. HTTP는 프로토콜, REST API는 설계 원칙이다.
REST는 HTTP 이후에 등장한 개념이다. 기존의 HTTP를 최대한 활용해서 웹 설계 원칙을 만들자고 해서 등장한 것이 REST인 것이다. HTTP가 먼저 나오고 REST가 그에 맞춰서 등장했기 때문에 REST 설계 원칙을 가장 잘 지키면서 사용할 수 있으면서도 가장 대중적인 프로토콜이 HTTP인 것이다.
설계 원칙으로써의 REST
REST는 Representational State Transfer(상태를 표현하는 통신)의 약자로 리소스를 중심으로 클라이언트와 서버의 리소스에 대한 표현으로 웹을 만들어서 더 효율적인 웹을 만들자는 설계 원칙이다.
리소스 중심? 리소스에 대한 표현? 뭔가 표현이 애매하다. 사실 우리가 태어나서 처음 웹을 사용했을 때부터 RESTful API를 사용했기 때문에 REST 설계 원칙이 당연하게 느껴져서 애매모호하게 들릴 수도 있다.
(국어의 문법을 처음 배울 때의 느낌처럼)
사실 우리가 체감을 하지 못하고 있지 모든 웹의 요청과 응답은 리소스에 대한 표현이다.
리소스에 대한 표현은 크게 3가지로 나뉜다.
-
리소스의 위치에 대한 표현이다. 클라이언트와 서버는 URI를 통해 리소스의 위치를 표현한다.
-
클라이언트가 리소스에 어떤 행위를 할 것인지를 나타내는 표현이다. 클라이언트는 HTTP 메소드를 통해 리소스에 어떤 행위를 취할지를 표현한다.
-
서버가 클라이언트의 요청을 받은 리소스의 상태가 어떤지를 나타내는 표현이다. 서버는 HTTP 상태 코드를 통해 리소스의 상태가 어떤지를 표현한다.
잘 생각해보면 우리가 웹을 이용할 때 위의 3가지 중 하나의 방법을 통해 리소스의 상태를 서술하는 방식으로 웹을 사용하고 있다.
