TIL - REST API : 누구나 읽기 쉽게 설계하기

REST란?

REpresentational State Transfer의 약자로, 자원(리소스)의 표현에 의한 상태 전달을 하는, HTTP를 잘 활용하기 위해 만든 ‘아키텍쳐’이다. 따라서 REST를 잘 지키지 않는다고 해서 ‘trash code’나 ‘동작하지 않음’ 이런것은 절대 아니다.

다만 내가 RESTful한 API를 설계한다면 다른 crue, 아니면 혹시나 내 업무를 넘겨받을 사람에게는 충분한 도움이 될 것이다.

 

문제 발생

플라스크를 이용한 프로젝트를 설계하고 구현하는 과정에서, 상대방이 시간이 없어 구동 방식이나 완성본을 보지는 못하고 메인 컨트롤러만 확인할 수 있는 상황이었다. 그런데 메인 컨트롤러의 코드가 너무 중구난방이고, URL에서도 이게 어떤 코드인지, 어떻게 동작하는지를 알 수가 없었다.

다음은 app.py에 들어있는 api의 url과 method다.

	URL	method	기능
home	/
search_get	/search	GET	검색 결과를 받아오는 메서드
list_post	/playlist	POST	플레이리스트에 추가하는 메서드
list_get	/playlist	GET	플레이리스트를 받아오는 메서드
list_update	/playlist	PUT	플레이리스트에서 삭제하는 메서드
getlogin	/auth/login	GET	로그인 화면을 렌더링하는 메서드
login	/auth/login	POST	로그인을 하는 메서드
logout	/logout	GET	로그아웃을 하는 메서드
getSignIn	/auth/signin	GET	회원가입 화면을 렌더링하는 메서드
signIn	/auth/signin	POST	회원가입을 하는 메서드

제일 문제인 것은, 지금 내가 이 포스트를 쓰면서도 이게 무슨 기능인지 몰라 다시 app.py를 열어봤다는 점이다.

 

해결

CRUD에 맞게 method를 설계했다고 생각은 하지만, directory나 url 설계과정에서는 전혀 RESTful하다고 느껴지지 않는다. Auth나 Playlist같은 directory를 만들어서 따로 관리했어야 했다.

또한 code-convention이 잘 되지도 않았고(snake와 camel의 혼용) 내가 가지고 있는 resource가 무엇인지도 잘 파악되지 않는다.

URL같은 경우에는 users/{id}/playlist같이 동적 라우팅을 해 주는것이 좋다.

지금은 리소스를 활용하는 프로젝트가 아니기도 하고, 코드가 많이 들어가는 복잡한 작업은 아니지만 git을 활용할 때 충분히 conflict 문제가 날 수 있는 문제이다.

그래서 url등의 문제를 다음과 같이 바꿔 준다.

	URL	method	기능
home	/
search	/users/{id}/search	GET	검색 결과를 받아오는 메서드
addList	/users/{id}/playlist	POST	플레이리스트에 추가하는 메서드
getList	/users/{id}/playlist	GET	플레이리스트를 받아오는 메서드
updateList	/users/{id}/playlist	PUT	플레이리스트에서 삭제하는 메서드
getLogin	/login	GET	로그인 화면을 렌더링하는 메서드
login	/login	POST	로그인을 하는 메서드
logout	/logout	GET	로그아웃을 하는 메서드
getSignIn	/signin	GET	회원가입 화면을 렌더링하는 메서드
signIn	/signin	POST	회원가입을 하는 메서드

다음 목표는 method를 나누지 않고 methods=['GET', 'POST']로 하는걸로..