REST API
REST API
웹개발자라면 REST API 를 이미 알고 있거나 사용해보았을것이다. 사실 개발자가 아니더라도 우리는 REST API 를 거의 매일 사용할 것이다.
REST API 는 네트워크 통신상에서 두 주체가 자원을 (resource) 주고 받는 방식을 정의한다. 서버와 클라이언트 또는 서버와 서버사이에서 사용할 수 있다.
리소스는 사진, 비디오, 텍스트 그 어떠한 데이터가 될 수 있다. 리소스를 소유하는 서버쪽에서 각 리소스를 고유하게 식별하고 클라이언트가 접근 할 수 있도록 URL 을 제공한다. (이때 클라이언트는 단순히 요청을 하는 주체의 의미에서의 클라이언트고 서버 또는 클라이언트 어플리케이션에 제한을 두는것이 아니다.)
특정 리소스에 대한 요청을 받은 서버는 그 데이터를 특정한 형태로 만들어서 응답으로 돌려준다. 여러 형태의 예시로는 JSON, XML, HTML 등 다양하다.
따라서 REST 단어 자체를 풀어서 보면 Respresentational State Transfer 이다. 여기서 “representational” 은 서버가 자원을 특정 형태로 나타내는 방식을 의미하고 “state” 는 자원 그리고 “transfer” 은 통신을 의미한다.
RESTful design 특징
client-server architecture 요청을 보내는 클라이언트와 응답을 하는 서버의 상호작용으로 이루어진다
Statelessness 각 요청은 요청에 필요한 모든 정보를 담고 있고 서버는 각 요청을 독립적으로 다루고 처리한다. 즉 요청과 요청 사이의 데이터를 기록하거나 저장하는 행위는 하지 않는다.
Cacheability 서버에서 보내는 응답은 캐싱을 통해 저장하고 재사용 가능한 형태이다.
Layered System 계층화된 소프트웨어 설계로 REST API 서비스의 구성 요소들을 만든다. 따라서 구성 요소들을 변경하거나 추가하더라도 API 자체는 계속해서 같은 방식으로 작동하도록 설계한다.
Code on Demand 이부분은 가능한 특징이고 무조건 있어야 하는 특징은 아니다. 응답에 실행되야할 코드를 넣어서 자동으로 클라이언트단에서 로직을 수행하게 하는 특징이다. 실제 이런 API 를 사용하거나 만들어보지 않아서 꽤나 생소하게 다가왔다.
Uniform interface 특정 자원은 항상 같은 형태로 응답되어야 하고 사용자가 필요한 모든 정보를 담고 있어야 한다. 예를 들어 강아지에 대한 데이터라면 강아지 이름, 나이, 견종 등 같은 정보의 형태로 매번 돌려주어야 한다.
API 요청
요청하고 싶은 자원에 대한 URL 이용하고 HTTP method 를 통해 자원에 어떤 작업을 하고 싶은지 명시한다. HTTP method 는 동사 형태의 단어들이다. 따라서 URL 은 명사형태고 따로 동사를 나타내는 단어를 넣지 않는다.
대표적인 HTTP method 는
- GET - 읽기
- POST - 새로 추가/만들기
- PUT - 수정
- DELETE - 삭제
예를 들어 URL 은 https://example.com/api/v1/dog 이면 URL 에 GET 요청을 보내면 서버에 등록되어 있는 강아지 데이터를 응답으로 돌려주는 식이다.
API 응답
응답은 대표적인 요소가 두가지이다. 하나는 상태 코드 (status code) 와 응답 바디이다 (response body).
상태 코드는 세자리 숫자 형태인데 숫자마다 고유한 의미를 나타낸다. 크게 분류하면
- 2xx - 200 번대는 요청이 성공하였다는 의미를 나타낸다
- 3xx - 300 번대는 리다이렉션을 의미하고 사용자 쪽에서 추가적인 액션을 취해야한다는 의미다.
- 4xx - 400 번대는 요청에 문제가 있어서 처리할 수 없음을 의미한다.
- 5xx - 500 번대는 서버쪽에서 문제가 생겨 요청을 처리를 실패했다는 의미다.
보통 요청을 성공적으로 처리하면 응답 바디에 자원을 나타내는 데이터를 돌려주고 요청에 실패하면 실패한 사유에 대한 정보를 넣어주는게 일반적이다.
REST API 그 이전과 왜 오늘날 REST 가 인기가 많은지
REST 이전에는 클라이언트와 서버의 관계 개념을 만들어서 어플리케이션을 만들기 어려웠다. 예를 들어 브라우저에 보여지는 웹 어플리케이션의 UI를 서버단에서 HTML 로 렌더링하고 그 결과값을 응답으로 보내주는 식이 대표적인었던걸로 알고 있다.
이런식으로는 어플리케이션을 확장하고 관리하기 매우 힘들다.
REST API 을 통해 오늘날 흔히 사용하는 클라이언트와 서버의 관심사 분리가 된 아키텍처가 쉽게 가능해졌다.
REST 이전에는 SOAP 이라는 통신 규약도 있었다. REST 와 비슷하게 데이터를 주고 받을 수 있는 방식을 정의하고 있다. SOAP 단점은 유연성이 떨어지고 사용하기 더 까다롭다는 것이다. 예를 들어 SOAP 는 XML 형식으로만 데이터를 주고 받을 수 있다.