Open API Document 도입에 대해 #312
Replies: 3 comments 2 replies
-
캬 너무 좋아요!!
질문도 있습니다! |
Beta Was this translation helpful? Give feedback.
-
개인적으로 swagger UI를 좋아해서 좋아보이네요 ㅎㅎ (docs는 문서의 성향이기 때문에 보여지는 부분이 상당히 중요하다고 생각 !) 몇 가지 궁금한 점이 있습니다 😀 첫 번째, 저는 yaml 파일을 읽어보니 스웨거를 애플리케이션 코드단에 작성하지 않고 yaml 파일에 그대로 옮겨놓은 것 같더라구요 ! yaml 파일이기 때문에 프론트 백엔드 구분없이 작성할 수 있다는 장점은 존재하지만, 결국 swagger 설정을 yaml 파일로 그대로 작성하기 때문에(정확히는 잘 모르겠지만?)현재 진행하고 있는 노션에 작성 -> yaml 파일에 작성 과정을 동일하게 반복할 것 같다는 생각이 들어요 !! 두 번째, 이전에 어떤 docs를 사용할 지 토론을 진행했었습니다 ㅎㅎ 그 과정에서 rest docs를 사용하기로 했던 이유 중 하나가 마지막으로 Rest docs는 배포를 해야 변경된 부분을 확인할 수 있는데, OAS도 결국 yaml을 바탕으로 swagger config를 생성해주는 것 같은데 배포를 하지 않고 적용할 수 있나요?!?!!? (가능하다면 정말 멋있는 친구 💚) |
Beta Was this translation helpful? Give feedback.
-
지금 다시 생각해봤을 때 다음과 같은 문제점이 인지되어 지금은 close 하겠습니다~
|
Beta Was this translation helpful? Give feedback.
-
서론
현재 문서화 방식에서 다음과 같은 문제를 인지했습니다.
최근 API First Design이라는 기법에 대해 찾아보던 도중 Open API Specification에 대해 알게 되었습니다.
OAS
RESTful API를 사전에 정의된 규칙에 맞게 API 스펙을 json이나 yaml로 표현하는 방식을 의미합니다.
yaml로 작성된 코드로 swagger 문서를 생성할 수 있습니다.
더 나아가 해당 yaml 파일과 CodeGen을 이용한다면 실제 문서화를 위한 코드까지 작성할 수 있다는 특징이 있습니다.
현재 명세되어있는 API를 yaml로 간단하게 작성해봤습니다.
해당 방식을 사용하면 단 하나의 명세서를 사용하여 API 변경에 따른 문서의 불일치 현상을 최소화 할 수 있다는 장점이 있습니다.
또한 yaml 언어 자체가 직관적이고 OAS와 관련한 문서화도 잘 되어있어 익숙해지는 데에도 큰 문제는 없다고 판단했습니다.
요약
두개 이상의 문서를 관리하면서 발생하는 불필요한 소요를 줄이고 싶었습니다.
이를 위해 OAS를 도입하여 하나의 문서로 API 스펙을 관리하는 방법을 생각해봤습니다.
여러분은 OAS 도입에 대해 어떻게 생각하시나요?
예시 코드
아래 코드를 https://editor-next.swagger.io/ 해당 사이트에 붙여넣기를 해서 생성되는 문서를 미리 확인해볼 수 있습니다.
Beta Was this translation helpful? Give feedback.
All reactions