RESTful API
예전에 RESTful API에 대한 글을 작성했던 글을 보고, 다시 내용도 정리할 겸
블로그 이전 작업도 할겸 해서 다시 한번 해당 내용에 대해서 정리해 보고자 한다.
개념
우선 단어에 대해서 하나하나 뜯어보도록 하자.
프론트엔드 개발자가 아무리 기깔난 화면을 구성했다고 하더라도,
사용자와의 상호작용을 처리하지 못하면 그냥 이쁜 쓰레기일지도 모른다. (물론 아닌 경우도 있지만)
그래서 서버와의 지속적인 통신을 통해 사용자의 상호작용에 대한 데이터를 전달하고 응답을 통해 사용자에게 보여줘야 하는데
이를 가능하게 하는 것이 API다.
좀 더 쉽게 예시를 들어보자면 우리가 맥날을 가서 캐셔에게 '베토디 세트 하나 주세요' 하면
캐셔가 주문서를 누르게 되면 주방에 전달이 돼서 베토디가 만들어져서 나오고, 우리가 베토디를 전달 받는 이 상황에서
우리가 클라이언트, 주방이 서버라고 한다면 캐셔가 API가 되겠다.
그렇다면 REST는 무엇인지 알아보면 Representational State Transfer의 약자다.
풀이하자면 상태(State)를 전달(Transfer)하는 것을 나타내는(Representation) 방법이다.
즉, 자원을 이름(자원의 표현)으로 구분하여 해당 자원의 상태(정보)를 주고 받는 것을 의미한다.
그렇다면, RESTful API는 뭘까? RESTful API는 REST 원칙을 따르는 API를 의미한다.
결과적으로 RESTful API를 뜯어보면 클라이언트와 서버가 통신을 할 때 어떠한 매개체를 이용하는데
통신에 대한 자원을 이름으로 관리하는 방식의 원칙을 따르는 것이라고 생각하면 되겠다
특징
REST는 HTTP 프로토콜을 기반으로 하고, 자원을 고유한 URI로 식별해, HTTP method를 사용해 조작한다.
그래서 REST API 역시 HTTP 프로토콜이 갖고 있는 stateless의 특징이 있다.
또한 stateless 특징을 가졌을 때, 발생하는 통신 비용에 증가에 따라 캐시 정책을 사용할 수 있는 특징도 있다.
REST API의 장점은 여러가지가 있지만 가장 명확한 장점은 self-descriptiveness 즉, 스스로 설명이 가능하다라는 점이다.
RESTful API는 그 자체만으로도 API의 목적이 쉽게 이해 될 수 있게 한다.
이런 API의 장점을 살리기 위한 설계 원칙이 존재한다.
1. URI는 동사를 제외한 명사로 구성하고, 대문자보다는 소문자를 사용한다
BAD : [GET] /user/show/1
GOOD : [GET] /user/1
2. 리소스에 대한 행위를 HTTP method 만으로 표현한다.
BAD : [DELETE] /user/delete/1
GOOD : [DELETE] /user/1
3. 마지막에 슬래시 (/)를 포함하지 않는다.
4. 언더바(_) 대신 하이픈 (-)을 사용한다.
5. 파일 확장자는 URI에 포함하지 않는다.
Summary
API는 클라이언트와 서버와의 통신을 하게 해주는 매개체이고,
이러한 통신 과정에서 통신에 대한 자원을 이름으로 관리하는 방식이 REST 방식이다.
RESTful API의 가장 큰 장점은 그 자체만으로도 API의 목적이 쉽게 이해된다는 부분인데
이러한 장점을 살리기위한 다양한 설계 원칙이 존재한다.
레퍼런스
- PAYODA 블로그 글 [ 이동 ]
- 그린 클라이언트 블로그 글 [ 이동 ]
- 히진쓰님 블로그 글 [ 이동 ]