개발을 시작한지 얼마 안된 시점에서 프로그래밍 언어의 기초 문법을 배우고 나면 백엔드 개발자들은 가슴에 불 같은 열정을 안고 하루 빨리 API를 만들고 싶은 욕망으로 가득차 있을 것이다.
나 또한 그랬었고, 급한 마음에 간단한 API를 설계 후 통신을 해본 후 백엔드 개발자가 된 것 마냥 흥겨운 느낌만 앞섰다..
하.지.만. 급하게 만든 API는 따지고 보면 화이트보드지에 그린 유치원생들 조차 그릴 수 있을만한 그림 밖에 되지 않았고 받아들이는 사람 입장에서 혹은 통신하는 클라이언트 입장에서는 난해하기만 했다.
이런 개발자들의 문제를 해결하기 위해 조금 더 정규화된 여러가지의 설계 규칙 혹은 인터페이스가 존재하는데 대표적인 것들로는 REST API, GraphQL, FALCOR 등이 있지만 오늘은 그 중 가장 대중적으로 쓰이는 REST API에 대해서 알아 볼 예정이다.
✍ REST API란..
REST API는 Representational State Transfer의 약자로 HTTP 개념 설립의 주 기여자인 로이 필딩이 당시 웹 설계의 우수성을 널리 알리기 위해 설계한 웹 아키텍처로써 상태(State)를 전달(Transfer)하는 것을 나타내는(Representation)방법이다.
위에 쓰인 사전적 정의가 다소 어려울 수 있으니, 쉽게 풀이하자면 자원을 특정지어 구분 한 후 요청한 상태에 따라 자원을 주고 받는 것이라고 해석하면 될 것 같다.
사실 필자도...처음에는 저 설명조차 난해하여 직접 REST API를 설계하면서 익혀왔다.
그렇기에..하나 하나씩 알아보자.
✍ REST API의 장/단점
📝 장점
- HTTP 프로토콜의 인프라를 사용하기에, 별도의 인프라 구축이 필요 없다.
- HTTP 프로토콜의 장점을 고스란히 가져온다
- HTTP 프로토콜을 사용하는 모든 플랫폼에서 유용하게 쓰인다
- Hypermedia API의 기본을 지켜 범용성이 좋다.
- REST API의 설계 규칙을 따르게 되면 의도한 바가 명확하여 전달력이 좋아진다 (Self-Descriptiveness).
📝 단점
-
보안에 취약하기 때문에 기밀 자료를 다루는 API에 있어서는 부적합하다.
-
HTTP 프로토콜을 사용하기에 다양성이 떨어진다.
✍ REST API의 설계원칙
RESTful API를 설계하기 위해서는
- CLIENT-SERVER : Client / Server 독립성 분리
- Stateless : HTTP의 Stateless와 동치
- Cache : Stateless 방침을 해결하기 위한 보완책
- Uniform Interface : 통일적 관리
- Layered System : 관심사 독립적 분리
- Code on Demand : 클라이언트 내 즉시 실행
상위에 있는 총 6가지의 설계 원칙을 알고 넘어가면 좋겠지만 내용이 상당하기에 가장 직권적인 Uniform Interface만 간단하게 짚고 넘어가보자.
📝 Uniform Interface
- 명확한 자원의 식별
=> "URI를 통해 자원을 명확하게 식별"
자원을 명사 형태로 다음과 같이 정확하게 표현
/products/1: 1번 제품/users/1: 1번 유저
- 표현을 통한 자원에 대한 조작
=> 자원에 현재 상태 (자원의 format)
-
Self-Descriptiveness
-
HATEOAS
=> 쉽게 말해 하이퍼미디어를 통한 앱 상태를 변경하는 것
✍ REST API의 경고!
사실, REST API에 대해서 아주 조금 파고들기 전까지는 REST API는 단순하게 HTTP 메서드를 동사로 생각하고 자원은 명사로 생각하여 관계를 명확히 하는 것이 전부라고 생각했다..하지만 2008년 로이 필딩이 한 강의에 따르면, 대부분의 개발자들이 REST API는 HTTP 기반의 인터페이스를 가진다면 전부 REST API라고 치부하는 경우가 있다고 한다.. 그 중 나도 하나이기도 하고..아직 REST API에 대한 모든 개념을 이해한 것이 아니기에 내가 지금도 설계하고 있는 API가 RESTful한 API라고 할 수는 없으나..이 점을 인식하고 조금씩이라도 가까워지기에 노력을 해보자.
