API 설계 원칙

 

1. Mutation 경우 Input Payload가 명시적으로 설계되어야 한다.

- 사용자 정의 데이터가 사용자 입력에 따라 자유로운경우(JSON) 해당 데이터는 검증도 하지 않아야한다. 즉, 저장하고 그대로 내려준다

- 그외에 JSON형태지만 틀이 정해져있는 경우에는 검증을 해야한다

- Input Payload 기반으로 추후에 서비스 로직에서 해당 데이터를 사용한다면 클라이언트가 계산후 결과를 Input에 받도록 설계해야한다

 

2. 이전 버전과의 호환성(Backward compatibility)을 보장해야합니다.

- 기존 API의 요구사항이 변경이 되었을때 기존 API에서 반환하는 데이터타입이나 필드를 제거하지 않고 새로운 필드를 추가합니다 기존 필드는 deprecated 처리합니다

 

3. API 개발시 통합테스트를 구축합니다.

- 비즈니스가 발전하면서 수많은 API가 자동배포되는 상황에서 최소한의 API를 테스트 할수 있는 중간 규모의 테스트가 필요합니다

- 기존 API가 변경될때 중간 규모의 테스트도 추가 개발되야 합니다

 

4. 배포 파이프라인에 Blue/Green 또는 Canary 배포에 대한 준비가 필요합니다.

- 무중단 배포를 지원하는 솔루션이 많이 존재하므로 배포로 인해 서비스 장애가 없도록 배포 파이프라인을 구축해야 배포에 대한 두려움이 줄어듭니다 쓸데없는 배포 문서나 다양한 채널에 배포한다는 공유가 업무에 추가되지 않아야 합니다