REST(REpresentational State Transfer)는 HTTP/1.0과 1.1의 스펙 작성에 참여했고 아파치 HTTP 서버 프로젝트의 공동 설립자인 로이 필딩의 2000년 논문에서 처음 소개된 개념입니다.
발표 당시 HTTP를 제대로 사용하지 못하고 있는 상황을 보고 HTTP의 장점을 최대한 활용할 수 있는 아키텍처로서 REST를 소개했고 이는 HTTP 프로토콜을 의도에 맞게 디자인 하도록 유도하고 있습니다. REST의 기본 원칙을 지킨 서비스 디자인을 RESTful 이라고 표현합니다.
즉, REST는 HTTP를 기반으로 클라이언트가 서버의 리소스에 접근하는 방식을 규정한 아키텍처고, REST API는 REST를 기반으로 서비스 API를 구현한 것을 의미합니다.
REST API의 구성
REST API는 자원, 행위, 표현의 3가지 요소로 구성됩니다. self-descriptiveness(자체 표현 구조)로 구성되어 REST API만으로 HTTP 요청의 내용을 이해할 수 있습니다.
REST API 설계 원칙
REST에서 가장 중요한 기본적인 원칙은 두 가지 입니다. URI는 리소스를 표현하는데 집중하고 행위에 대한 정의는 HTTP 요청 메서드를 통해 하는 것이 RESTful API를 설계하는 중심 규칙입니다.
URI는 리소스를 표현해야 한다.
URI는 리소스를 표현하는 데 중점을 두어야 합니다. 리소스 명은 동사를 사용하지 않고 명사를 사용해야 하죠. get/delete 등의 행위에 대한 표현이 들어가서는 안됩니다.
// bad
GET /getTotods/1
GET /todos/show/1
// good
GET /todos/1리소스에 대한 행위는 HTTP 요청 메서드로 표현한다.
HTTP 요청 메서드는 클라이언트가 서버에게 요청하는 종류와 목적(리소스에 대한 행위)을 알리는 방법입니다. 주로 5가지 요청 메서드(GET, POST, PUT, PATCH, DELETE 등)를 사용하여 CRUD를 구현합니다.
- GET - 리소스 취득
- POST - 리소스 생성
- PUT - 리소스 전체 교체
- PATCH - 리소스 일부 수정
- DELETE - 리소스 삭제
리소스에 대한 행위는 HTTP 메서드를 통해 표현하며 URI에 표현하지 않습니다. 예를 들어, 리소스를 취득하는 경우 GET, 리소스를 삭제하는 경우 DELETE등을 사용하여 행위를 명확히 표현합니다.
// bad
GET /todos/delete/1
// good
DELETE /todos/1Restful한 API의 어려움
방금 살펴본 핵심 원칙 외에도 REST는 세부적인 규칙들을 갖고 있습니다. 그러나 REST의 모든 원칙을 지키는 일은 생각보다 어려운 일입니다. 간단히 예를 들어보겠습니다.
로그인과 로그아웃을 표현하려고 하고 있습니다. 로그인을 하는 경우 ID, PASSWORD등을 body에 표현해야 하기에 다음과 같이 표현할 수 있습니다.
POST /users
어떤가요? 혹시 회원가입처럼 보이시진 않나요?
로그아웃은 어떻게 표현할 수 있을까요?
DELETE /users/id
PUT /users/id
PATCH /users/id
혹시 리소스의 변경이나 삭제처럼 보이지 않나요?
이처럼 간단한 예시에서도 Rest를 지키며 API를 설계하는 것은 어려운 일입니다. 오히려 아래와 같은 예시가 개발자로서 더 올바르게 판단되죠.
POST users/login
PUT users/logout
로그아웃은 POST로 표현하는게 더 알맞을 수도 있겠네요. 이렇듯 REST는 API설계에 큰 도움을 주지만, 모든 규칙을 지키며 설계를 하긴 매우 어렵습니다.
개발자는 이점을 염두해두고 REST의 기본 원칙을 지키되, 강박적으로 세부적인 내용에 집착하지 않고 의미론적으로 알맞는 방법을 찾을수도 있어야 합니다.
무엇이 정답인지는 모르겠습니다. 그러니 더더욱 발전해야 겠습니다.
출처
- 모던 자바스크립트 딥 다이브, 이웅모, 위키북스
