역사적으로, 시스템 간 인터페이스 설명은 건축가와 통합자의 전유물로, 종종 데이터 구조가 포함된 이메일 교환으로 축소되었습니다. SOA 시대와 특히 마이크로 서비스 아키텍처 시대에 시스템 분석가는 통합 계약의 형식화 및 지원에서 중요한 역할을 하게 되었습니다.
잘못되거나 불완전하거나 오래된 API 인터페이스 설명은 서비스 불일치, 버그 증가, 시스템 전체가 하나의 파급 효과 없이 변경할 수 없는 원인이 됩니다. 멀티 서비스 프로젝트에서는 통합 지점 수가 수십 또는 수백 개에 이를 수 있습니다.
시스템 분석가는 현대의 관행을 적용합니다:
중요한 요소는 계약의 올바른 버전 관리와 변경 추적을 유지하고 상호 작용을 검증하기 위한 테스트 사례 통합입니다.
주요 특징:
분석가는 API 요구 사항을 고객 및 내부 개발자와만 수집해야 합니까?
아닙니다, 모든 통합 팀을 참여시켜 외부 파트너의 요구 사항을 고려하는 것이 중요하며, 이를 통해 공백이나 불일치를 피할 수 있습니다.
시스템 인도 단계에서만 API를 문서화할 수 있습니까?
아닙니다, API 사양은 구현 전에 형성되어야 하며, 그렇지 않으면 각 단계에서 하위 호환성이 손상될 것입니다.
OpenAPI 사양이 모든 교환 사례에 대한 충분한 문서라고 할 수 있습니까?
아닙니다, OpenAPI는 구조를 설명하지만, 상호 작용 시나리오(예: 호출 순서, 사건의 순서, 비즈니스 오류)는 분석가가 사용자 문서에 명확히 기술해야 합니다.
부정적 사례: 물류 시스템이 외부 운송업체와 통합되었습니다. 계약서는 "단어"로만 설명되었습니다. 변경 사항이 발생한 후 대규모 통합 실패와 지연이 발생했습니다.
장점:
단점:
긍정적 사례: 분석가는 오류/성공 사례 예와 함께 OpenAPI 를 작성하고 버전을 조율하며 모든 팀으로부터 피드백을 수집했습니다.
장점:
단점: