API는 ui에 종속되지 않아야한다.

프로젝트를 진행하며 사용자 정보를 수정하는 api를 만들었다. 피그마에 명시된 화면은 이런식이다.

get '/users/me' 내 정보 가져오기

patch '/users/nickname' 닉네임 수정하기

patch '/users/profile-image' 프로필 이미지 수정하기

delete '/users/profile-image' 프로필 이미지 삭제하기

patch '/users/comment-alarm/on' 댓글 알림 켜기

patch '/users/comment-alarm/off' 댓글 알림 끄기

patch '/users/update-alarm/on' 업데이트 알림 켜기

patch '/users/update-alarm/off' 업데이트 알림 끄기

delete '/users' 회원탈퇴하기

ui에 맞추어 버튼(동작)마다 각각 api를 생성하였다.

이 api 설계에는 두가지 문제가 있었다.

첫번째 문제 - 가독성이 떨어지는 api 경로

나는 내 정보를 가져오는 api는 get '/users/me' 이렇게 설계하고, 닉네임을 수정하는 api는 patch '/users/nickname' 이렇게 설계하였다.

이 api는 매우 모호하다. users/me로 가져왔으면 내 닉네임을 수정하는 api는 patch '/users/me/nickname' 이렇게 작성하여야 했다. api를 읽어가며 유저 테이블의 나의 닉네임을 patch이렇게 읽을 수 있도록 해야했다.

이렇게 되면 밑의 api도 모두 알아보기 어려운 형태가 된다. 프로필 이미지를 수정하는 api도 patch '/users/profile-image'게 아닌 patch '/users/me/profile-image'가 되어야한다.

두번째 문제 - api는 ui에 종속되지 않아야 한다.

나는 피그마에 나와있는 대로 버튼마다 모든 api를 설계하였다. 나는 ui에 종속된 api를 설계하고 있었다.

하지만 api는 ui에 종속되지 않아야한다. 왜 그럴까?

• 재사용성 : 먼저 재사용성에서의 접근이다. 만약 웹 서비스만 하던 어플리케이션이 어플로 까지 확장된다고 생각해보자. 그렇다면 그에 맞추어 모든 api를 추가해야할 것이다. 이는 매우 비효율적이다. 하지만 ui에 종속되지 않고 설계한다면 코드의 재사용성을 높이고 개발 및 유지 보수 비용을 줄일 수 있다.

• 확장성: 그 다음은 재사용성에서 이어진 확장성으로의 접근이다. 만약 여러 사용자의 요구에 따라 ui가 변경되거나 삭제/추가 될 수 있다. 그렇다면 이렇게 ui 바뀔때마다 모든 api를 수정해 주어야하는 상황이 발생한다.

이런 이유 말고도 여러가지 이유가 있지만, 내가 체감할 수 있는 이유는 아직 여기까지이다. 따라서 이에 맞추어 api를 수정하였다.

get '/users/me' 내 정보 가져오기

patch '/users/me' 내 정보 수정하기

delete '/users/me' 회원탈퇴하기

이렇게 3개의 api로 축소하고 우리 서비스는 닉네임,이미지,알림여부등을 모두 user table하나에서 관리하기 때문에 닉네임, 이미지, 알림 여부 수정을 하나의 form으로 묶어서 처리하였다. 이렇게 하면 후에 기능이 추가되거나 어플리케이션으로 개발이 이어지더라도 "내 정보 수정" api는 조금만 맞추어 수정하면 여전히 동작할 수 있을 것이다.