[TIL] 99클럽 코테 스터디 30일차 TIL : 팀을 위한 RestAPI 규칙

📖 오늘의 학습

---

 오늘은 RestAPI 명명법에 대해 생각을 해봤다. 회사에서 백엔드 팀과 논의하는 과정에서 RestAPI URL은 어떻게 할 지가 안건으로 나왔다. 사실 그동안에는 프론트엔드 입장에서 RestAPI 명세는 헷갈리지만 않으면 되는 문제라고 생각을 했었는데, 오늘 다시 생각해보니 그러면 어떻게 해야 안 헷갈리게 할 수 있을까 하는 생각이 들었다.

 

 뭐든 그렇겠지만 각자의 입장에서 편한 부분이 존재한다. 백엔드는 백엔드의 관점에서 편한 부분이 있고, 프론트엔드는 프론트엔드의 관점에서 편한 부분이 존재한다. 너무 한쪽이 편한대로만 하는 것도 문제인데, 그것보다 더 큰 문제는 서로서로 괜찮다고 상대의 요구만 들어주는 것이다. 일종의 배려라고 할 수 있지만, 이게 반복된다는 것은 주관이 없다는 것과 같다. 이렇게 해야 프론트엔드 구조가 편하고, 백엔드도 편하게, 서로 상호보완적으로 프로젝트를 짤 수 있게 된다 라는 주관이 전혀 없이 진행된 프로젝트는 망하기 쉽상이다.

 

 그래서 오늘은 회사에서 RestAPI 명명법과 백엔드가 편한 작업, 프론트엔드가 편한 작업 등을 논의하고 각자의 의견을 밝혔다. 그러나 그 중에서도 논의가 안된 부분이 몇몇 있었는데, 이는 다음과 같다.

 

- RestAPI URL에 camelCase를 사용하는 이유

- snake_case를 사용하지 않으려는 이유

- 이름을 지을 때, 명사를 단수와 복수로 나누었을 때의 장점과 단점

- 단수만 사용했을 때의 장점과 단점

- RestAPI URL에 primary key 혹은 userId와 같은 것을 Path Parameter로 두어 노출시켰을 때의 문제점

 

 어느정도 합의가 된 부분도 있고, 이야기가 나오지 않은 것도 있는데 뭐가됐건 그 이유를 정확하게 알아야한다는 생각이다. 왜 그렇게 했는지에 대한 합리적인 이유가 없다면 처음부터 다시 정해야한다고 생각한다.

 

🤔 오늘의 회고

---

 이유, 명분 이런 것들은 단순히 통과받기 위함이 아니라 이후의 프로젝트에 엄청난 영향을 끼치게 된다. 지금까지 이유없이 무언가를 했는데도 큰 문제가 없었다면 운이 좋았기 때문이라고 생각한다.

 

 그리고 오늘의 문제는 코드가 사실상 재탕이다. 달라지는게 없다. 템플릿 우려먹기 정도의 문제였던거 같다.