현재 프론트엔드에서 api 명세서를 피드백을 하고 있습니다.
- api피드백을 개발을 하면서 해줘야하는건지 아니면 초기에 api명세서를 피드백을 다 하고 개발을 시작해야하는건지 궁금합니다!
- api 명세서를 어디까지 터치를 해야하는건지 궁금합니다.
- 1) 필드 네이밍 → 리더블한지.
- 3) / path → 응답
- /병원조회 → 약국
- 4) api 구조에대해서 피드백
2) 데이터 모델 → converting 비용이 높으면 (복잡도가 높으면)
{ a: 1, b: 2, } { a: { a1: 1, a2: 2, }, b: 2, }
개발을 하다가, 수정요청
- 필드명 수정
- 기존것은
deprecated
, 신규 추가 - home: …
- hame: ..
- 백엔드와의 협업관련해서 질문
- 1.
- 개발 전에는 1,2
- 와이어프레임에서 3,4피드백하면 best,시간이 없기때문에 개발하면서 피드백
- 2.
- 필드 네이밍 -> 이 필드에 담는 데이터가 해석이 잘 되는지(사람마다 관점이 다 달라서)
- 데이터 모델
- Float vs depth가 깊어지는 거는 모델에 대해서 피드백을 줘야한다.
- path에 맞춰서 잘 어울리는 응답을 줘야한다.(하면서 하는게 좋다)
- 중복되는 api들은 분리해서 관리하는게 좋다!(하면서 하는게 좋다)
- 개발하다가,수정요청
- 필드가 수정 => 기존꺼 그대로 유지 + 신규것도 추가 하면서 배포를 해야한다.
- 리스트를 받을때 내가 좋아요했냐?가 깔끔 -> 리스트를 받을때 내가 좋아요했냐+좋아요 개수만 받아도 되지않냐? === 매칭을 할 필요가 없지! => 비지니스 로직이 프론트엔드에서 처리가 된다는 단점이 있다. 프론트는 가공된 데이터를 받는게 괜찮다!(데이터 매핑만 시켜주고 ui 로직을 우선순위를 높여줘야한다!)
- 우리 기준으로 먼저 float하게 정리하고 백엔드에게 전달!(우리가 쓰기 편한걸로 역제안 해야한다),api는 최대한 클라이언트 친화적으로 달라고 해야한다