서론
먼저, 업무에 있어 원활한 의사소통은 중요합니다. 개발자는 항상 기획자들은 말도 안되는 것을 요구하고, 복잡한 기능을 간단한 기능이라며 요청한다고 분노합니다. 반면 기획자는, 개발자들은 항상 요청하면 불가능하다, 어렵다고 거부한다고 분노합니다. 이 간극은 서로가 가진 제반 지식이 다르기 때문에, 의사소통이 수월하게 진행되지 못하기 때문에 발생합니다.
같은 개발자 안에서도 FE개발자와, BE개발자는 각자가 가진 전문 역량이 다릅니다. FE개발자는 UX, UI와 웹페이지 렌더링에 관한 역량을 가지지만, BE개발자는 DB와의 연동을 위한 역량을 가지고 있습니다. 서로 가진 제반 지식이 다르기 때문에, 의사소통에서 어려움을 가지기도 합니다. 하지만 FE개발자와 BE개발자는 기능의 추가를 위해, 서버와의 통신을 위해 서로 다방면으로 소통하고, 협력해야 합니다.
서버와 클라이언트 간 데이터 통신을 위해 일반적으로 HTTP requests와 response 기술을 활용합니다. HTTP 통신은 메소드와 URL을 통해서 데이터의 조작 방식을 규정하지만, 느슨하게 규정되어 프로젝트마다 다르게 구현될 수 있습니다. 따라서 획일화된 디자인 패턴을 적용하여, 개발자들이 서로 편하게 소통할 수 있는 기회가 필요합니다. 그를 위해, 의사소통이 편리한 디자인 패턴인 RestAPI에 대해 지금부터 설명하겠습니다.
Rest API
RestAPI는 FE와 BE간 HTTP 통신의 규정을 위해 만들어진 디자인 패턴입니다. 중요한 대원칙 5가지는 아래와 같습니다.
1.
자원 기반의 URI
•
자원은 URI를 통해 표현되어야 한다.
2.
HTTP Method
•
자원의 조작은 HTTP Method를 통해 표현되어야 한다.
3.
무상태성
•
작업을 위한 모든 정보는 그 요청 안에 표현되어야 한다.
4.
캐시 가능성
•
응답 데이터의 재사용이 가능해야 한다.
5.
계층화
•
계층화를 통해 클라이언트와 서버 통신의 유연성과 확장성을 높여야 한다.
자원 관리를 위한 URI와 HTTP Method
커뮤니티 웹을 만든다고 생각해봅시다. 사용자는 클라이언트에서 글의 제목, 글의 내용을 작성하여 서버에 작성 요청을 보내게 될 것입니다. 우리가 RestAPI 원칙을 고려하지 않는다면, /make/posts URI에 Get 요청을 통해 작성 요청을 보낼 수 있습니다. 이 방식도 괜찮지만, http method가 post가 아닐 시에도, 새로운 리소스가 추가되는 방식은 다소 난잡해 보입니다.
따라서 URI에는 자원만 표현할 수 있도록, /posts URI에 Post 요청을 통해 작성 요청을 보내도록, URI에는 자원만을 표현하는 것이 좋습니다.
URI로 표현된 자원을 어떻게 조작할지는 HTTP Method를 활용하는 것이 Rest한 설계라고 할 수 있습니다.
무상태성
무상태성이란, 서버와 클라이언트 간의 요청이 독립적이라는 것을 의미합니다. 위와 같은 상황을 가정해 보겠습니다. /posts URI에 글의 제목과 내용을 보낼 수도 있으나, /posts/title, /posts/detail 두 개의 URI에 따로따로 전송하는 방법도 있습니다. 서버가 세션 인증을 기억하고 있으며, 같은 인증서 안에서 title 이후 들어온 detail을 하나의 post로 묶어서 처리하는 방법도 있습니다.
생각만 해도 끔찍하군요. 이유 모를 버그로 detail이 들어오지 않는다거나, 요청 중복이 생겨 title이 두 번 들어오는 등 변수에 따른 예외처리 로직이 끔찍하게 복잡해질 것입니다. Rest한 설계란, /posts URI에 글의 제목과 내용. 즉 작업에 필요한 모든 정보를 표현하는 것입니다.
캐시 가능성과 계층화는 서론에서 말한 것과 같이 의사 소통을 위한 설계론이 아닌, 코드의 유지보수나 프로그램의 성능 향상을 위한 방법론입니다. 이 글에서는 의사소통의 편리성을 위한 디자인 패턴을 기고하였으니, 설명에서 제외하겠습니다.
결론
REST API는 현재 대부분의 웹 개발 프로젝트에 적용될 정도로 널리 퍼진 디자인 패턴입니다. 명확하고 직관적인 설계를 통해 개발자들이 서로 의사소통할 시간을 줄일 수 있었습니다. 하지만 Rest한 설계만이 정답은 아닙니다. HTTP 프로토콜은 통신의 연속성을 보장하지 않기 때문에 무상태성을 보장하는 것이 권장되나, MQTT 등 TCP 연결을 유지하여 사용하는 통신에서는 무상태성을 필수로 보장할 필요는 없습니다. 중요한 건 꺾이지 않는 마음이듯, 중요한 건 개발자들 간 대화 없이 자료만 보더라도 한번에 알아챌 수 있도록 설계하는 것이 훌륭한 API 설계일 것입니다.