기능이 조금 변하면서 API도 바뀌었다.
그리고 동료 개발자로부터 API를 하나로 만들어서 한꺼번에 리턴값을 받는게 좋을것 같다는 피드백을 받았다.
만약 API 하나하나마다 서버에서 많은 처리를 해야한다면 API를 여러개 보내서 병렬 처리를 하는게 맞겠지만 저 API들은 모두 통계를 처리해야한다
그리고 이미 DB에서 통계를 반정규화시켰으므로 서버에서 처리에 많은 시간이 걸릴 것 같진 않다. 서버 처리보단 네트워크 오버헤드가 더 걸릴 것같기 때문에 API를 하나로 통합하기로 했다.
API가 하나가 되엇다.. 마음이 조금 허해지긴 했지만, 오히려 좋다
하지만 나중에 기능테스트에서 시간이 많이 걸린다고 판단된다면 다시 API를 나누는 것을 고려해봐야 할 것같다
+) 검색 API 설계
나는 검색 API를 /api/problems/keyword?name=? 으로 설계했었는데
/api/problems?name=? 으로 바꾸는게 더 낫다는 피드백을 받았다.
이때 나는 API의 수가 많아지는게 비효율적이기 때문이라고 생각했었는데 예상하지 못한 답변을 받았다.
물론 API의 수가 많으면 안 좋은것도 맞지만, 프론트의 입장에서 생각해보라는 말이었다. 프론트의 입장이라.. 전혀 생각치 못했다.
프론트의 입장에서 전체 검색이랑 일부 검색의 API가 다르다면, 검색했을 때 두 API를 구분해야하기 때문에 페이징 처리가 귀찮아질 수 있다
+) API 설계 효율성
문제 완료 업데이트 기능의 경우, 레코드 복습완료 후 DB에서 is_Completed를 true로 바꿔주기만 하면 된다. 종류는 통계지만, 효율성을 위해서는 레코드 복습완료 API에서 같이 처리해주는게 좋다.
하지만 가독성의 경우 분명히 다른 분야이므로 API를 다르게 처리하는게 좋다. 모든 것은 트레이드-오프이기 때문에 이번은 성능을 선택하는게 좋을 것같다.
