초기 벨로그 글엔 생각도 조금씩 작성했었는데 글이 정리되어 보이지 않아서 그냥 노트 처럼 쓰기 시작했어요.
그치만 개발자가 되기 위해선 본인만의 생각도 중요하는 걸 깨달았기에 정리가 안되있어보여도 글을 잘 쓰지 못 하더라도 써보려고 합니다 :) 쓰다보면 좋아지겠..죠?
테크 블로그글을 읽고..
당근 마켓 서버 개발자의 API 설계
오늘 당근마켓 개발자가 쓴 블로그를 보게되었습니다.
저는 당연히 design-first 접근 방식으로 설계 해야되는 줄 알고 그렇게 설계를 해왔었습니다.
api 설계 할 때 명세를 먼저 작성하는게 'design-first 접근 방식'이라고 용어가 있는지도 처음 알았습니다.
저는 프로젝트 개발 경험을 했었을 때 처음엔 당연히 그렇게 해야되는 줄 알고 노션을 사용해 API명세서를 작성했었어요
1. 팀노션에 API 명세 페이지를 만든다
2. API 명세를 작성한다
3. 클라이언트에선 앞서 작성된 API를 임시로 사용한다
4. 서버에서 API를 작성하고 완성된 API를 클라이언트에게 공유해 해당 API를 사용한다
대체적으로 위 처럼 진행되었는데 마지막 프로젝트 때 노션으로 API 설계시 수정된 API 명세를 다시 작성해줘야하는 번거로움과 API가 완성된줄 알았는데 수정되었을 때 정신이 없어 클라이언트에게 수정된 사실을 알리지 못 한 문제가 있었어요. 그래서 마지막 프로젝트, 좀 나중에 적용되긴 했지만 swagger를 사용해봤습니다.
새로 알게된 OAS
OpenAPI Specification 이라는 HTTP API를 정의하고 문서화하는 언어를 새롭게 알게되었어요
이걸로 API 명세를 작성하면 API 문서와 프로그래밍 언어의 코드를 자동으로 생성해준다는데 자세한건 사용해봐야 될거 같습니다
OAS 장점
- yaml 또는 json으로 API 명세를 작성해 수동으로 요청 응답을 작성하지 않아도 된다.
- 제안하는 규격이 있어 일관된 형식으로 API를 작성할 수 있다.
- 별도 저장소에서 관리해 찾기 쉽다.
- 최신성이 보장된다.
느낀점
솔직히 이때까지 프로젝트들을 진행하면서 API 명세가 중요하다는 걸 알고는 있었지만 주어진 기간내에 부족한 실력으로 개발을 하려니 API에 대해 진지하게 짚고 넘어간적이 없었습니다 체계적이고 확실하게 관리를 해야되는구나 하고 다시한번 깨닫게 되면 글이였습니다.
