
팀을 이뤄서 롤링페이지 웹앱을 만드는 사이드 프로젝트를 하고 있다.
나는 프론트엔드 개발을 맡았다. 그래서 백엔드 팀원들과 같이 API 명세서를 작성하는데,
롤링페이지의 색과 폰트를 미리 정해두고 각각에 번호를 부여해 1,2 이런식으로 데이터를 전달해주자는 이야기가 나왔다.
그런데 뭔가 말로 설명하지 못할... 찜찜함이 있어서 동료 개발자인 웨지님에게 물어보니 이런 답이 왔다.

## 클라이언트에게 불친절한, 서버 의존적인 API

![웨지님](/images/blog/2203/apitip.png)

카톡을 보고 무릎을 탁 쳤다!! **클라이언트에게 불친절한, 서버 의존적인 API** !!!

폰트나 컬러의 경우 폰트명, 헥사코드처럼 거의 합의된 형태의 이름/표현법이 있는데 이걸 코드로 관리하는게 비효율적으로 느껴졌다. '굳이...?' 싶었던 것이다.

번거로울 뿐더러 폰트와 컬러 데이터를 이름 대신 코드로 관리해 서버 측에서 다시 해석해야하기 때문에 서버 의존적이라고도 할 수 있다.
사용자가 폰트나 컬러를 선택해야하는 부분의 프론트 개발을 할 때 '이 코드가 무슨 색/폰트였지?' 싶어 찾아보게 될 게 뻔했다.

개발보다 기획과 설계가 더 어렵다. 서버/클라이언트 한 쪽에 과한 부담이 가지 않도록 신경 쓰며 개발해야겠다. 


적절한 표현을 찾았을 때의 스프라이트 샤워

API

'API'에 관한 글들을 모아봤어요.

클라이언트에게 친절한 백엔드 API 만들기