1. 구성
1.1. 총 411개의 API 제작(6 카테고리)
1.1.1. 생산(32)
1.1.2. 마케팅(20)
1.1.3. 세일즈(180)
1.1.4. 서비스(319)
1.1.5. 지불(88)
1.1.6. 규제(70)
2. 구성원
2.1. API Provider(공급자) - API로 데이터를 공개(제공)하는 조직
2.1.1. API를 만들때 고려사항
2.1.1.1. 1. 우선순위/API 제작 순위 지정
2.1.1.2. 기술적인 가이드라인·요구사항 식별·정의
2.1.1.3. 3. 개방성, 유용성, 상호 유연성을 고려하여 API 설계
2.1.1.4. 4. 차제개발/외주 선택
2.1.2. API 개발시에 고려사항
2.1.2.1. 1. (기능 요구) API의 예상 기능 정의
2.1.2.2. 2. ( 비 기능 요구 사항) API가 예상 기능을 얼마나 잘 수행하는지 측정하는 기준 정의
2.1.2.3. 3. (기술 지침) API가 필요한대로 작동 할 수 있도록 다양한 기술 지침 정의
2.1.2.4. 4. (승인) 정의 된 요구 사항의 포괄성 확인
2.1.3. API 디자인할때 중요 키워드
2.1.3.1. (개방성) 모든 사람이 API 접근 가능한지 확인
2.1.3.2. (사용 편의성) 고품질 보장
2.1.3.3. (상호 운용성) 특정 기술에 의존하지 않는 데이터 교환 방식
2.1.3.4. (재사용) 기존 표준 및 모듈 확인
2.1.3.5. ( 독립성) 특정 벤더 또는 기술의 의존성은 피해야 함
2.1.3.6. (확장성) 제작하는 API가 새로운 비즈니스에 활용될 수 있도록 유연성 확보
2.1.3.7. (안정성) 거너넌스 또는 커뮤니티에 의한 변화에 일관성과 transparency 확보
2.1.3.8. (transparency) 지원되는 환경 및 표준에 대한 명확성 제공
2.1.3.9. (낮은 결합도) 유연성 확보 및 다른API와의 결합도 최소화
2.2. FinTechs(플랫폼) - 앱·서비스 개발 회사, API 이용
2.2.1. 프로세스
2.2.1.1. 1. 개발시에는 API Provider에서 요구하는 사항 참조
2.2.1.2. 2. 사용할 때는 API의 기술 지침 참조
2.2.1.3. 3. 기존에 정의된 API 수정 금지
2.3. API Consumer(소비자) - API provider의 API를 사용하여 데이터를 이용하는 모든 조직 또는 사람
2.3.1. 프로세스
2.3.1.1. 1. 필요한 API 식별
2.3.1.2. 2. Open API 검색
2.3.1.3. 3. API 이용 지침 준수
2.3.1.4. 4. 유지보수 이용 지침 준수
2.4. Developer Community(API 개발) - API 개발 업체, FinTech 또는 API provider가 원하는 API 개발
2.4.1. 프로세스
2.4.1.1. 1. 요구사항 및 기술 지침 수신
2.4.1.2. 2. 기술 사양서 작성
2.4.1.3. 3. (REST) stateless protocol은 제한된 대역폭 및 리소스 사용해야 함
2.4.1.4. 4. (SOAP) 안정적인 운영 ·안정성·보안 보장
2.4.2. 설계/구현시 지침
2.4.2.1. API 데이터흐름(Data Flow) 계획·매핑
2.4.2.2. 앞으로의 상태 계획
2.4.2.3. 트래픽 고려 / 최대치에서 시스템에 미치는 영향
2.4.2.4. 이해하기 쉽고 유용한 결과 도출
2.4.2.5. 일반적인 Work Flow / 적은 API 사용
2.4.2.6. 일반적인 사례를 다룸
2.4.2.7. 반응성 등을 고려하여 프로그램 설계
2.4.3. 버전 관리
2.4.3.1. API 메이저/마이너 번호 사용
2.4.3.2. 변경사항에 대한 호환성
2.4.3.3. 하위 호환성
2.4.3.4. 릴리즈 변경 지원
2.4.3.5. 릴리즈 버전에 따라, 특정기간 유지보수
2.4.3.6. 취약점 발생시에 대처할 수 있는 확장성
2.4.3.7. 표준 적용(W3C 표준권장)
3. API
3.1. API 표준
3.1.1. 데이터(p.28~)
3.1.1.1. XBRL
3.1.1.2. OFX
3.1.1.3. ACCROD XML
3.1.1.3.1. ACORD P&C XML
3.1.1.3.2. ACORD Life & Annuity Standard
3.1.1.3.3. ACORD XML for Global Reinsurance and Large Commercial (GRLC)
3.1.1.4. FpML
3.1.1.5. EDIFACT
3.1.1.6. FIX
3.1.1.7. MDDL
3.1.1.8. SAML
3.1.1.9. SWIFT and ISO 20022
3.1.1.10. SDMX
3.1.1.11. HL7
3.1.1.12. HR-XML
3.1.2. 인증(p.33~)
3.1.2.1. OAuth2.0
3.1.2.2. OpenID Connect
3.1.2.3. SAML 2.0
3.1.2.4. 2FA
3.1.3. 인가(p.38)
3.1.3.1. OAuth2.0
3.1.3.2. ISO 10181-3
3.1.4. 암호화(p.39)
3.1.4.1. TLS ver.1.2
3.1.4.2. RSA
3.1.4.3. AES 128/192/256
3.1.5. 데이터 무결성(p.40)
3.1.5.1. SFTP
3.1.5.2. JWT
3.1.5.3. WS-Security
3.1.5.4. HMAC
3.1.6. 보안 호스팅
3.1.6.1. ISO27001
3.1.6.2. ISO22301
3.1.7. PCI DSS
3.2. 작성 프로세스
3.2.1. 1. 가이드라인 작성
3.2.2. 2. 데이터표준
3.2.3. 3. 관련 표준 확인
3.2.4. 4. 거너넌스 메카니즘 구현
3.3. 거버넌스
3.3.1. 생명주기(life cycle)
3.3.1.1. 1. 아이디어 - API 수익 창출, 비즈니스 모델 및 드라이브 산출물 확대
3.3.1.2. 2. 생산 - 프로토타입, 세부 서비스 개발
3.3.1.3. 3. 게시 - 정책 집행, 사용자 채택 분석 및 생태계 확장
3.3.1.4. 4. 소비 - 사용 전에 관리사항(서비스 관리, 계약, 보안, IP 및 법률) 확인
3.3.1.5. 5. 퇴직 - 버전 변경 알림 및 변경
3.3.2. 위험관리
3.3.2.1. 1. API Customer 정의/구축
3.3.2.2. 2. API Risk Catalog 정의/관리
3.3.2.3. 3. API Process Maps 정의/관리
3.3.3. 컴포넌트
3.3.3.1. API 포털 - API의 프레임 워크, 디자인, 라이프 사이클, 문서화 및 게시를 관리
3.3.3.2. API 청구 - 공개 및 외부 API의 경우 청구서 처리
3.3.3.3. API 게이트웨이 - 라우팅, 다중 소유 및 보안 (인증 및 권한 부여)과 같은 런타임 활동에 필요한 지침 및 관리
3.3.3.4. API Service Manager - API 구성, 정책, 변경, 배포, 수정을 관리
3.3.3.5. API Cashback - 서비스 / API가 필요한 기대치를 충족시킬 수 없을 때 캐시백
3.3.3.6. API 모니터 - API의 성능 및 품질에서 발생하는 런타임 문제 처리
3.3.4. 프레임워크(p.43)
3.3.4.1. 프로세스: Plan, Define, Enable, Mesure
3.3.4.2. p.44 에서 거버넌스 참조 모델 개요도 참조