API 설계를 하며 깨달은 점

깨달음의 발단: https://github.com/f-lab-edu/SSKA/pull/47#discussion_r1070973660

 

 

나는 지금까지 어떤 기능을 만들 때는 꼭 해당 기능 맞춤형 API 하나가 만들어져야 한다고 생각했다. 그런데 그게 아니었다.

기능이 있다고 그 기능의 API 하나를 설계 해야 하는 것이 아니라 그 로직을 설계 해야 하는 것이었다.

 

우리가 Restful 하게 API를 만드는 것은 리소스를 생성, 수정, 삭제, 조회하는 것이지 특정 기능만을 위한 api는 아니다

 

이번 SKKA 프로젝트를 하면서 "좌석 시간 변경" 기능을 만들고 API를 붙이려고 할 때, 해당 프로젝트에는 API가 총 4개가 있는데 ("좌석 예약", "좌석 이동", "좌석 이용 시간 변경", "좌석 예약 취소/퇴실") 기능별로 꼭 하나의 API를 설계 해야 한다고 생각하고 있었던 것이었다.

 

 

이렇게 하다 보니 코드의 반복이 계속 되었다. 그러다 보니 코드가 복잡해지며 서비스 로직에서 하나의 메소드에서 하나의 역할에 충실하지 못한 메소드가 나와야했다. 이것을 해소하기 위해서는 코드의 재사용이 필요했다. 예를 들어 "좌석 이동" 기능을 개발할 때 여러 로직들이 다른 API 에서 사용되는 서비스, 도메인 로직이 겹쳐, 이를 해결하기 위해  해당 기능("좌석 이동")을 개발할 때 "좌석 예약 기능"을 사용하면 풀리는 문제였다.

 

즉, 

 

이런식으로 "좌석 예약" 기능을 이용하여 다른 기능을 하는 API를 추가하면 코드의 반복을 줄일 수 있고 코드의 재사용이 가능해지며 하나의 역할에 충실할 수 있는 구조가 되었다.