의문점
API 요청 설계를 하며 생긴 의문점이다.
스터디 그룹장이 그룹원을 강퇴시키는 기능과 그룹원이 스스로 나가는 것이 어떻게 보면 같은 기능이다.
다만, 조건이 다르다. 그룹장이 강퇴시키는 경우 그룹장이 맞는지 검증하는 과정이 필요하고 그룹원이 스스로 나가는 경우 요청을 보내는 본인이 맞는지 검증하면 된다.
여기서 생기는 의문점이 강퇴기능과 탈퇴기능을 분리할 것이냐? 말것이냐?다.
이 밖에도 다양한 경우에서 api요청을 얼마나 세분화 할 것이냐에 대한 고민을 자주하게 되는 것 같다.
1. 코드의 중복과 가독성
코드의 중복(그래봤자 같은 메서드를 호출하는 한줄이지만..)과 가독성을 생각하면 하나의 api요청으로 처리하는게 좋을 것 같다.
(cf. 요청하나 당 처리하는 역할을 파악하고자 하는 관점에서는 분리하는 경우가 더 가독성이 좋다고 볼 수 있다고도 생각한다. 다만, 여기서는 api요청의 갯수가 많이 늘어나서 코드량 자체가 늘어가는 부분을 부정적으로 본 것이다.)
2. 확장성
추후에 코드를 수정하게 될 경우 다른 동작에 영향을 줄 수 있기 때문에 분리해서 각각 다른 api요청으로 처리하는게 좋을 것 같다.
3. 성능
조건문 한줄 밖에 안된다고 치더라도 묶여있는 형태의 api요청 설계는 목적에 필요없는 로직을 거쳐가야할 수 있다. 이런점을 생각하면 각각 다른 api요청으로 처리하는게 좋을 것 같다.
API 분리기준
- 독립적인 기능 단위
- API 요청을 최대한 쪼개서 독립적으로 사용할 수 있을 정도까지 나눈다.
- 일반적인 규모에서는 크게 상관이 없지만,
대규모 기준으로는 최소한으로 동작할 수 있도록 구현하는게 좋음.
- 요청 횟수 및 데이터의 크기에 따라 분리
- 요청 시간(크기) 범위를 조정해서 API를 구분할 수 있음
- CRUD 및 자원단위
- 한 API 범주 안에서 독립적인 기능을 할 수 있도록 하자
- 리소스를 생성하거나 조회하는 단위가 어떤 단위로 떨어지는지 확인
- 동일한 기능이지만 처리 기능이 다른 경우
- 동일한 API: API 본인 / 투표 / 강제 탈퇴
. 요청부터 엔드포인트를 분기 -> 처리
. 요청 시 API 세분화. 요청은 동일 -> service에서 분기하여 파라미터 넘기기 -> 처리
어느정도 중복 코드가 있더라도 REST API 위주로!
-> 요청을 직관적으로, 모호하지 않게 구현하는게 가장 중요함
결론
코드의 중복 < 성능
다소 중복코드가 발생하더라도 REST API를 지키는 선에서 api 분리를 통해 성능을 향상 시키는걸 더 우선시 하는게 좋다. 성능을 기준으로 선택하는 것을 우선시하면 될 것 같다.
cf. 물론 나누는 기준을 잡는 것 보다 어떤식으로 나누던지 팀원과 공유하고 파악하는 커뮤니케이션이 가장 중요하다!
