SA 수정과 피드백

1. API 명세서와 ERD에 대한 회의

1. url endpoint를 권한 별로 나누는 건에 대한 문제

API 명세서를 작성할 때, 권한별로 URL을 만드는 게 나을지, 아니면 그냥 Role 체크만 하는 방식으로 하는 게 맞는지에 대한 이야기가 나왔다.

위와 같은 방식으로 url이 구성된다면 Restful하지 않은 거 같다라는 이야기였다.

하지만 권한별로 API의 url이 구성된다면 endpoint만으로도 페이지의 권한이 노출되기 때문에 보안상 좋지 않을 거 같다는 의견이 나왔고, 이를 토대로 결국 url에 권한은 노출되지 않게 되었다.

2. url과 테이블명의 단수복수 표기문제

그 다음으로는 API url과 테이블명을 단수로 할지 복수로 할지에 대한 이야기가 나왔다. 검색으로만 봐도 단수가 맞다는 말도 있고 복수가 맞다는 말도 있어서 도대체 뭐가 정답이지? 하고 회의를 이어갔다. 우리 팀에 함께하고 계신 경력직 개발자 분께서는 현업에서 항상 단수를 사용하셨다고 했고, 나의 경우 최근 프로젝트는 복수를 사용했지만 원래는 단수가 맞다고 인식하고 있었다.

일단 가독성이 단수가 더 좋다는 의견으로 인해 단수로 결정이 되었고, 추후에 경력직 개발자분이 알아오신 정보에 의하면 예전에는 url을 무조건 단수로 설정해서 개발했지만 요즘에 개발되는 Restful API의 경우 복수로 쓰는 추세라고 했다.

내가 짬뽕으로 알고 있는 이유도 여기에 있었다. 시니어 개발자들은 단수로 알고있고, 주니어 개발자들은 복수로 알고있는 경우가 많은 것이다.
결론적으로는 회사마다, 프로젝트마다 다르니 내규를 따르세요가 정답인 듯 하다.

2. 튜터님의 피드백

• endpoint의 경우 권한 별로 나누는 것이 안되는 건 아니다. 그러나 msa로 확장할 때 문제가 생길 수 있다.
  • api에 권한이 들어가게 되면 msa로 나누었을 때의 구조가 이상해진다. 회원테이블도 권한이 있고 상품테이블도 권한이 있기 때문이다.
  • 경험상 결국 msa 구조에서 가장 적합한 것은 RESTful한 api 방식이라는 점이었다.

우리는 테이블마다 겹치는 Name의 경우 userName이나 productName 등으로 변경해서 작성했다. 그러나 개발자 관점에서 이 부분은 세부적으로 userName이나 productName 등으로 변경할 필요는 없다고 피드백해주셨다.

만약 DB를 프론트 팀이 보게된다면 겹치는 컬럼명으로 인해 대화에서 대화가 꼬이지 않게 하려고 넣은 부분이라 말씀드리니 프론트와 처음부터 Dto부터 설정하고 시작했더니 그런 문제가 없더라는 이야기도 해 주셨다. (물론 그건 쉽지 않은 일이라고도 하셨다.)

etc

그러고보니 오늘도 영어공부를 해야한다.

아, 그리고 플로우차트를 작성해보라고 해서 한 번 작성해보았다.

대충 이런 식으로 작성해보았는데, 팀원 분들이 고치라고 하는 부분이 있다면 수정할 예정이다.