API 설계 우선 원칙

0. API 떡밥은 쉬었지만 여전히 핫하니까, 그냥 나도 덥썩.

1. API의 개발 책임(?)/주도권(?)이 프론트엔드에 있는지 백엔드에 있는지는 중요한 게 아니다. 중요한 건 API 설계임. 하나의 API 앱에 다 때려박을 수도 있고, API를 수십개로 쪼갤 수도 있고, 그건 회사마다 상황에 따라 다르게 선택하면 되는 건데, 그게 설계단에서 검증을 해야 함.

2. 일단 API는 한 번 만들어진 후 배포를 하면 없앨 수가 없다. 없앨 수는 있겠지만 해당 API 엔드포인트를 누군가 쓰고 있다면, 그 사용자가 없어지기 전 까지는 없앨 수가 없음. 그래서 API는 변경 비용이 비싸다고 하는 것임.

3. 10년 쯤 전에 다니던 직장이 API 플랫폼 장사를 하던 회사였고, SOAP 기반 웹서비스로 API 장사를 했더랬는데, XML 노드 하나 추가하는 것은 괜찮지만, 변경하거나 삭제하는 건 최소 6개월의 depreciation 노티스를 줬다. 그 기간동안에는 신규 API와 기존 API를 둘 다 지원해야 했음.

4. 보통 마이크로서비스 아키텍처든 모놀리식 아키텍처든 기존에 사용하던 API들이 많다면 그것들을 묶어주는 API를 따로 만들기도 하고, 프론트엔드 쪽에서는 해당 프론트엔드 쪽에만 맞춤형으로 기존 API들을 묶어서 사용하기도 한다. 이를 BFF 패턴이라고 하는데, 이건 사실 코어 API하고는 크게 상관이 없음. 그걸 백엔드 쪽에서 관리하기엔 무리데스. 사실 BFF는 굳이 신규로 API를 개발할 필요도 없이 API 게이트웨이 수준에서 충분히 처리가 가능하기 때문이기도 함.

5. 그러니... API 설계나 잘 하쟈. 그러라고 OpenAPI 쓰는 것 아니겠음?

6. API 설계 우선 원칙에 대해 예전에 이상한 모임 하면서 2015년인가 2016년인가부터 목놓아 부르짖었지만, 아직도 이게 새롭다는 게 더더욱 신기함. 그 때 한창 한국 개발자 커뮤니티에서 API 얘기 엄청 헀던 것 같던데...

7. 그러니 이 책 한 번 잘 읽어보고 API 설계 잘 하면 좋겠다...

https://www.yes24.com/Product/Goods/124127840

난 이 책하고는 1도 관계 없음