왜 API 를 잘 설계해야하는가?
API 는 한 번 만들어지면 사용자가 있을 때까지 유지되어야 하기 때문입니다.
API 를 잘못 만들면 어떻게 되는가?
- 고객을 위해서 새로 만들어줘야함.
- 유지보수 비용 들어감.
- 사용자 경험 저하
웹 API 설계를 하기 위한 요소에는 어떤 것이 있는가?
- 비즈니스 관점에서 기여
- 비즈니스 문제를 얼마나 API 로 잘 해결했는가?
- 예시를 들면, 카페에서는 커피를 판매하는 게 주요 미션이니까 POS 시스템을 구축해서 관리한다. 이런 것처럼 API 설계는 핵심 비즈니스를 위해서 설계를 해야함.
- 프로덕트 중심 (고객의 문제 해결, 재사용성, 확장성 등)
- API 를 잘 만들어서 고객의 문제를 해결할 수 있어야한다. 고객의 이야기를 들어보는게 정말 중요.
- 고객 맞춤형 보다는 재사용성을 높혀야한다. 왜? 여러번 API 개발하는 건 비용이니까. "이미 있는거 쓰세요" 이렇게 말하려고. API 설계를 잘하면 개발자의 인건비를 아낄 수 있음.
- 확장성 있어야한다. API 를 사용하는 고객이 많아지더라도 쉽게, 싸게 스케일링을 제공할 수 있어야겠지.
- 개발자 경험 중요
- API 문서화를 잘해서, API 를 사용하는 개발자들이 편하게 나에게 질문없이 사용할 수 있도록 만드는게 중요하다.
API 설계 디테일
- 네트워크 통신 프로토콜을 결정해야한다.
- HTTP 를 쓸 지, gRPC 를 쓸 지, MQTT 나 AMQP 를 쓸 지,
- 모듈화
- 모듈화를 통해 재사용성을 늘릴 수 있다. 시스템들은 모듈의 집합으로 이뤄지는 것처럼, 모듈들을 잘 만들어 놓는다면 재사용할 수 있다.
- API 제공 자체를 모둘화 해야하며, API 를 제공하는 시스템 안에서도 모듈화를 잘 해둬야한다. 그냥 조합해서 쓰면 되도록.
- 높은 응집도와 낮은 결합도
- 낮은 응집도를 제공한다면, 원하는 결과르 얻기 위해서 하나의 API 만 호출하면 될 걸, 여러 API 를 호출해야 할거다. 그러면 이를 지원하기 위한 서버 비용이 증가함.
- 리소스 기반의 API 가 되야한다.
- 그러니까 클라이언트와 API 제공업체가 대화를 할 수 있는 시나리오가 있어야한다. 이렇게되면 사용자가 원하는 걸 제공해줄 수 있을테니까.
API 설계 유스 케이스
- 반복되는 일을 API 사용으로 해결해서, 임직원들이 그 작업을 하는데 소요되는 시간을 줄일 수 있다.
일관성있고, 확장성 있는 API 란 무엇인가?
- 일관성 있다는 건, API 를 데이터 모델이나 객체로 설계하지 않다는 걸 이야기하는 듯하다. 데이터 모델과 객체는 계속해서 변경하는데 이거에 맞춰서 API 도 변경되면 안되니까.
- 확장성은 위 참고.
References: