RESTful
백엔드 개발자라면 REST라는 단어를 무조건적으로 접하게 된다.
REST란 Representational State Transfer의 약자로 URI를 통해 자원을 명시하고 Method를 통해 관리하는 방법이다.
이러한 REST를 따르는 것을 RESTful이라 한다.
DELETE /members/11번 사용자를 삭제하고 싶다면 위와 같은 URI, Method를 사용할 것이다.
GET, POST, PUT, PATCH, DELETE와 같은 행위를 HTTP Method라 한다.
HTTP URI는 members를 자원, 1을 식별자로 사용한다.
클라이언트의 요청에따라 서버는 TEXT, JSON, XML 등 여러 형식으로 응답할 수 있는데, 이 것을 Representation이라 한다.
즉, REST는 다음과 같은 구성 요소를 가진다.
- 자원(URI)
- 행위(Method)
- 표현(Representation)
REST를 따른다면 URI와 Method를 통해 의미를 파악하기 쉽다.
하지만 모든 행위를 자원과 한정된 행위로 나타내기에는 한계가 존재하기 때문에 URI에 행위를 적거나, 옛날 서버에는 GET 요청 시 Body를 읽을 수 없을 수 있기 때문에 Read 시 Body가 필요한 경우 POST를 쓰는 등 명확한 표준이 존재하지 않다.
REST API
REST를 기반으로 한 RESTful API를 일컫는다.
현재의 클라이언트 <-> 서버 기반의 웹 아키텍처에서 거의 필수적인 형태이다.
하지만 URI를 통해 자원을 명시하고 Method를 통해 행위를 지정한다고 REST API를 처음으로 논문에 발표한 Roy Fielding이 말하는 것과는 다르다.
진정한 REST API가 되기 위해서는 Uniform Interface의 Self-descriptive, HATEOAS를 만족해야한다.
Selft-descriptive는 custom media type이나 profile link relation 등으로 data를 설명하여 만족시킬 수 있다.
HATEOAS는 Header 혹은 Body에 링크를 담아 만족시킬 수 있다.
우리는 편의상 정석적인 REST API는 아니지만 REST API라고 일컫는다.
이부분은 여기에서 자세히 설명하고 있다.
