예를들어 피드 생성에 성공에 대한 response인데 해당 피드가 공개 피드 생성 했을때 response와 비공개 피드 생성시 response를 보다 구체적으로 swagger로 제공 해준다면 프론트 엔드 개발자 입장에서 swagger 문서에 대한 가독성이 굉장히 올라갈것이다.
응답 실패시
기존 피드 삭제 에러 response swagger
404 에러 코드에 해당하는 에러 경우가 2가지인데 1. 2. 이런식으로 메세지만 구별되어 있어 구체적이지 못하고 가독성이 떨어진다.
끝으로 보다 직관적이고 구체적인 응답을 프론트 엔드 개발자에게 제공하여 프론트 엔드 개발자에게 함께 일하고 싶은 백엔드 개발자가 되자
: 추가
외부 api를 사용하는데 하나의 enpoint에 다른 response 응답값이 오는 경우에 직관적이고 구체적인 swagger를 제공 했을때와 아니였을때의 차이를 알아보자
외부 api에서 제공 해주는 swagger
내가 만약 해당 Swagger를 제공 받은 프론트엔드 개발자라면 이게 무엇인지 이해가 안되고 틈만 나면 백엔드 개발자에게 물어봐야 할것이다. 즉, Response dto schema를 참고하라고 보통 할텐데 숙박(32) : 테이블여부 이런식으로 프로퍼티가 열거형으로 되어 있고 해당 프로퍼티를 다 열어보면서 작업해야 되서 가독성이 굉장히 떨어진다.
