[1]의  9장에서는 API의 계약 문서화와 이해 관계자들과 커뮤니케이션을 위한 패턴을 다룬다.

1. API 설명

  • 설명: API의 기능, 메시지 구조, 동작의 의미 등을 문서화하여 클라이언트 개발자가 이해할 수 있도록 한다. OpenAPI와 같은 기술적 계약 설명 언어를 사용할 수 있다.
  • 주요 특징:
    • 상호 운용성 보장
    • 정보 은닉 유지
    • 확장성과 진화 가능성 지원
  • 포스의 충돌:
    • 지나치게 복잡한 설명은 유지보수에 어려움을 주고, 간단한 설명은 상호 운용성을 해칠 수 있음.
    • 정보 은닉과 상호 운용성 사이의 균형을 유지해야 함.

2. 요금 책정 플랜

  • 설명: API 사용량에 따라 요금을 청구하는 플랜을 정의하는 패턴. 구독 기반 요금제, 사용량 기반 요금제 등이 있으며, 고객의 사용량을 정확히 측정하고 요금 부과.
  • 주요 특징:
    • 경제적 측면, 정확성, 세분성, 보안 등의 고려 필요
    • 구독형, 사용량 기반, 시장 기반 등의 요금제 변형 가능
  • 포스의 충돌:
    • 사용량 측정과 청구의 정확성을 유지하면서, 비용 효율적인 방법을 찾아야 함.
    • 고객의 만족과 프로바이더의 수익성 사이의 균형 유지 필요.

3. 사용 비율 제한

  • 설명: 클라이언트가 API를 과도하게 사용하는 것을 방지하기 위한 패턴. 주기적으로 재설정되는 간격 기반 전송률 제한을 사용하여 과도한 요청을 차단하거나 제한.
  • 주요 특징:
    • 경제적 측면과 성능 보장
    • 남용 방지 및 신뢰성 유지
  • 포스의 충돌:
    • 너무 엄격한 제한은 사용자의 불만을 초래할 수 있으며, 너무 느슨한 제한은 시스템의 안정성을 해칠 수 있음.
    • 서비스 품질과 클라이언트의 자유로운 사용 사이의 갈등을 조율해야 함.

4. 서비스 수준 계약 (SLA)

  • 설명: API가 제공하는 서비스의 품질을 명시적으로 정의한 계약. 특정 서비스 수준 목표(SLO)를 포함하여, 이를 충족하지 못했을 때의 벌칙이나 보상 등을 규정.
  • 주요 특징:
    • 가용성, 성능, 보안, 법적 준수 등의 품질 특성 측정 가능
    • 소비자 관점에서의 매력도 향상
  • 포스의 충돌:
    • 높은 품질 보증은 프로바이더에게 높은 비용과 위험을 수반할 수 있음.
    • 클라이언트의 신뢰를 얻으면서도 비용 효율적인 방법을 찾아야 함.

 

참고 문헌
[1]  올라프 짐머만 , 미르코 스토커 , 다니엘 뤼브케 , 우베 즈둔 , 세자레 파우타소 , "마이크로서비스 API 디자인 패턴: 쉬운 통합을 위한 결합도 최적화 전략" 에이콘. 이승범 역

[1]의  8장에서는 다룬 API 진화 패턴을 다룬다. 각 패턴에 대한 설명, 주요 특징, 그리고 충돌하는 요구 사항(포스)을 포함한다.

변경 사항 도입 패턴:

  1. 공격적 폐기
    • 설명: 이전 버전을 빠르게 폐기하고, 클라이언트에게 빠르게 신규 버전으로 전환하도록 강제.
    • 주요 특징:
      • 사용 빈도가 낮은 기능을 신속히 제거.
      • 유지 관리 비용 절감.
      • 최신 버전 채택 촉진.
    • 포스:
      • 신속한 혁신과 클라이언트 안정성 간의 균형.
      • 빠른 전환이 어려운 클라이언트와의 충돌 가능성.
  2. 실험적 미리 보기
    • 설명: 초기 버전을 미리 공개하여 클라이언트가 테스트하고 피드백을 제공할 수 있게 함.
    • 주요 특징:
      • 초기 채택과 피드백 장려.
      • 정식 출시 전 API를 개선할 수 있음.
    • 포스:
      • 불안정한 기능 노출의 위험.
      • 기능의 안정성과 클라이언트 기대치 관리 필요.
  3. 2개의 상용 버전
    • 설명: 기존 버전과 새로운 버전을 동시에 유지하여 점진적인 전환 지원.
    • 주요 특징:
      • 클라이언트의 중단 없는 전환 가능.
      • 역호환성 제공.
    • 포스:
      • 여러 버전을 유지 관리하는 데 필요한 자원 증가.
      • 새로운 기능과 이전 버전 지원 간의 균형.
  4. 제한적 수명 보장
    • 설명: API 버전의 지원 기간을 명확히 설정.
    • 주요 특징:
      • 버전 지원 종료 시점을 명확히 하여 클라이언트의 계획 수립 도움.
    • 포스:
      • 클라이언트의 기대치와 실제 지원 기간 간의 조율 필요.
      • 더 긴 지원이 필요한 클라이언트와의 충돌 가능성.
    •  

버전 표시 패턴:

  1. 버전 구분자
    • 설명: 명확한 버전 식별자를 사용하여 API 업데이트 구분.
    • 주요 특징:
      • 역호환성 관리.
      • 클라이언트가 특정 버전을 선택할 수 있게 함.
    • 포스:
      • 버전 관리 규칙의 엄격한 제어 필요.
      • 여러 버전이 동시에 사용될 때의 어려움.
  2. 시멘틱 버전 관리
    • 설명: 구조화된 버전 체계(예: major.minor.patch)를 사용하여 변경의 성격을 표시.
    • 주요 특징:
      • 버전 간 호환성 이해를 간편하게 만듦.
      • 중요한 변경 및 신규 기능을 명확히 신호.
    • 포스:
      • 새로운 기능 추가와 역호환성 유지의 균형 필요.
      • 일관된 버전 규칙 준수가 요구됨.

호환성 보장 패턴:

  1. 서비스 수준 계약(SLA)
    • 설명: API의 가용성, 성능 및 지원에 대한 명확한 기대치를 설정.
    • 주요 특징:
      • 클라이언트에게 안정성을 보장.
      • 신뢰성과 가동 시간 기준 설정.
    • 포스:
      • 안정성을 보장하면서 지속적인 개선을 하는 것의 충돌.
      • 높은 기준을 유지하기 위한 비용 부담.

참고 문헌
[1]  올라프 짐머만 , 미르코 스토커 , 다니엘 뤼브케 , 우베 즈둔 , 세자레 파우타소 , "마이크로서비스 API 디자인 패턴: 쉬운 통합을 위한 결합도 최적화 전략" 에이콘. 이승범 역

[1]의  7장에서는 주로 메시지 설계 품질을 개선하는 다양한 패턴과 접근 방식을 설명한다. API의 직관적 이해, 성능, 진화 가능성과 같은 품질 요소의 중요성을 설명하며, 성능과 보안, 확장성 등의 상충하는 요구 사항 사이에서 균형을 맞추는 방법을 다룬다. 패턴을 크게 나누면, 케시지 크기 및 요청 수 조정, 참조 관리 그리고 제어 및 표현 정도에 따른 패턴으로 구분할 수 있다. 각 패턴의 설명과 주요 특징, 그리고 패턴 적용 시 발생할 수 있는 주요 요구 사항인 '포스(force)' 충돌에 대해 요약한다.

메시지 크기 및 요청 수 조정하기를 위한 패턴

  1. 요청 번들
    • 설명: 여러 작은 요청을 하나의 큰 요청으로 묶어 클라이언트가 여러 번의 요청을 보내지 않도록 한다.
    • 주요 특징:
      • 네트워크 대역폭 절약
      • 응답 지연 시간 감소
      • 클라이언트 구현 단순화
    • 포스의 충돌:
      • 처리 복잡성 증가 vs. 성능 최적화
      • 클라이언트-서버 간 데이터 일관성 유지 필요
  2. 조건부 요청
    • 설명: 클라이언트가 이미 보유한 데이터와 서버의 데이터를 비교하여 변경된 데이터만 전송받도록 한다.
    • 주요 특징:
      • 네트워크 사용량 감소
      • 서버 및 클라이언트 간 데이터 일관성 유지
    • 포스의 충돌:
      • 효율성 vs. 추가 구현 복잡성
      • 상태 관리 필요성 증가
  3. 페이지네이션
    • 설명: 대량의 데이터를 청크로 나누어 클라이언트가 순차적으로 필요한 데이터만 가져오게 한다.
    • 주요 특징:
      • 대용량 데이터의 효율적 전송
      • 클라이언트의 메모리 사용 최적화
    • 포스의 충돌:
      • 데이터 최신성 vs. 성능 최적화
      • 네트워크 안정성과 리소스 사용 조정 필요

참조 관리의 대안으로서 패턴

  1. 임베디드 엔티티
    • 설명: 필요한 데이터를 응답 메시지에 직접 포함하여 클라이언트가 추가 요청 없이 필요한 모든 데이터를 얻도록 한다.
    • 주요 특징:
      • 관련 데이터의 한 번에 전송
      • 클라이언트-서버 간 추가 요청 최소화
    • 포스의 충돌:
      • 데이터 일관성 vs. 메시지 크기 증가
      • 전송 시간 증가와 대역폭 소비
  2. 링크된 정보 보유자
    • 설명: 관련 데이터를 직접 포함하는 대신, 해당 데이터를 참조하는 링크를 제공하여 필요 시 클라이언트가 추가 요청을 통해 접근할 수 있게 한다.
    • 주요 특징:
      • 메시지 크기 감소
      • 독립적 데이터 관리 가능
    • 포스의 충돌:
      • 효율성 vs. 추가 요청 필요성
      • 데이터의 최신성 유지 vs. 데이터 접근 지연

제어 및 표현의 정도에 따른 패턴

  1. 위시 리스트
    • 설명: 클라이언트가 요청 시 필요한 응답 데이터의 속성만 지정하여 선택적으로 데이터를 요청한다.
    • 주요 특징:
      • 데이터 전송 최적화
      • 클라이언트의 요구에 맞춘 맞춤형 응답 제공
    • 포스의 충돌:
      • 성능 최적화 vs. 클라이언트 복잡성 증가
      • 정확한 데이터 전달 vs. 데이터 취합의 어려움
  2. 위시 템플릿
    • 설명: 클라이언트가 중첩된 데이터 구조에서 필요한 부분만을 요청하여 더 세부적으로 응답을 조정할 수 있다.
    • 주요 특징:
      • 데이터 과다 전송 방지
      • 세밀한 데이터 제어 가능
    • 포스의 충돌:
      • 데이터 간결성 vs. 클라이언트-서버 간 데이터 처리 복잡성
      • 성능 향상 vs. 클라이언트의 정확한 요청 설계 필요

 

참고 문헌
[1]  올라프 짐머만 , 미르코 스토커 , 다니엘 뤼브케 , 우베 즈둔 , 세자레 파우타소 , "마이크로서비스 API 디자인 패턴: 쉬운 통합을 위한 결합도 최적화 전략" 에이콘. 이승범 역

[1]의 6장은 API 설계와 관련된 내용으로, 특히 요청 및 응답 메시지에 포함되는 메시지 표현의 설계에 대한 다양한 패턴과 고려 사항을 다루고 있다. 클라이언트와 프로바이더 간의 상호 운용성, 성능, 보안, 유지보수성을 보장하기 위해 요청 및 응답 메시지의 표현을 설계하는 것이 중요하다. 또한, 메시지 표현은 데이터 구조의 복잡성과 효율성 간의 균형을 맞추어야 한다. 메시지 표현의 과제는 여러가지가 포함된다. 메시지 크기, 대화의 복잡성, 상호 운용성, 지연 시간, 처리량, 확장성, 유지보수성, 개발자 경험 등 다양한 요소를 고려해야 한다. 그리고, 클라이언트와 프로바이더의 독립적인 배포 가능성을 확보하는 것이 중요하다.

 

패턴 소개

1. 데이터 엘리먼트 (Data Element)

설명:
데이터 엘리먼트는 API 요청 및 응답 메시지에서 도메인 모델 개념을 표현하는 기본 구성 요소이다. 클라이언트와 프로

바이더 간의 통신을 위한 핵심 데이터 구조로 사용된다. 구조화된 데이터로서, 아토믹 파라미터, 파라미터 트리 등 다양한 형태로 존재할 수 있다.

 

주요 특징:

  • 도메인 모델의 복잡한 개념을 추상화하고 구조화하여 데이터 표현을 용이하게 함.
  • 클라이언트와 프로바이더 간의 느슨한 결합(loose coupling)을 촉진해 유지보수성 향상.
  • 데이터 계약(data contract)을 통해 클라이언트가 데이터 구조를 이해하고 상호작용할 수 있게 함.

포스 충돌:

  • 풍부한 기능 vs. 성능: 복잡한 도메인 모델을 노출할수록 클라이언트에게 더 많은 기능을 제공할 수 있지만, 그만큼 성능 저하와 유지보수의 어려움이 있을 수 있다.
  • 보안 vs. 구성의 용이성: 데이터를 많이 노출할수록 보안 위협에 노출될 가능성이 크며, 이에 따라 구성 및 처리 부담이 커질 수 있다.
  • 유연성 vs. 유지보수성: 다양한 표현을 제공하여 유연성을 높이려다 보면 유지보수의 어려움이 생길 수 있다.

 

2. 메타데이터 엘리먼트 (Metadata Element)

설명:
메타데이터 엘리먼트는 요청 및 응답 메시지의 데이터를 설명하거나 보충하는 추가 정보를 제공한다. 이는 메시지의 의미를 명확히 하거나 처리 효율성을 높이는 데 사용된다.

제어 메타데이터, 애그리게이티드 메타데이터, 출처 메타데이터 등 다양한 변형이 있다.

 

주요 특징:

  • 데이터의 의미, 출처, 상태 등의 추가 정보 제공으로 상호 운용성(interoperability)을 강화.
  • 메시지 수신자가 데이터를 더 잘 해석할 수 있도록 도움을 줌.
  • 클라이언트가 데이터 처리와 분석을 효율적으로 할 수 있도록 정보 제공.

 

  • 포스 충돌:
    상호 운용성 vs. 결합도: 메타데이터가 많아질수록 해석이 쉬워져 상호 운용성이 향상되지만, 클라이언트와 서버 간의 결합도가 높아질 수 있다.
  • 사용 편의성 vs. 성능: 메타데이터가 메시지 크기를 늘려 처리 성능을 저하시킬 수 있다.
  • 보안 vs. 관리 용이성: 메타데이터에 보안 정보가 포함될 때, 관리의 복잡성이 증가할 수 있다.

 

3. ID 엘리먼트 (ID Element)

설명:

  • ID 엘리먼트는 API의 엔드포인트, 동작, 메시지 표현을 고유하게 식별하기 위한 데이터 요소이다. 클라이언트가 특정 데이터를 정확히 요청하고 처리할 수 있도록 한다.
  • UUID, URI, URN 등 다양한 형태로 제공될 수 있으며, 글로벌 고유성과 로컬 고유성을 보장할 수 있다.

주요 특징:

  • 각 데이터 요소를 고유하게 식별하여 명확한 참조를 가능하게 함.
  • 글로벌 고유성(예: UUID)과 로컬 고유성(예: 특정 세션 내에서만 유효한 ID)으로 나뉨.
  • 분산 시스템에서도 안정적인 데이터 참조가 가능.

 

포스 충돌:

  • 노력 vs. 안정성: 로컬 ID는 생성이 쉽지만, 글로벌 고유성을 보장하기 어려울 수 있습니다. 반면, 글로벌 ID는 관리가 복잡하지만 안정적이다.
  • 가독성 vs. 보안: 사람이 읽기 쉬운 ID는 보안에 취약할 수 있으며, 무작위화된 ID는 보안은 좋지만 가독성이 떨어질 수 있다.
  • 구조화 vs. 간결성: 데이터베이스 키와 같은 구조화된 ID는 효율적이지만, 관리의 복잡성을 초래할 수 있다.

 

4. 링크 엘리먼트 (Link Element)

설명:

링크 엘리먼트는 메시지 내에서 데이터 요소 간의 관계를 명확히 하여, 클라이언트가 필요한 데이터를 찾고 추가 요청을 수행할 수 있게 합니다. 하이퍼미디어 컨트롤의 일환으로 사용된다. REST API에서 중요한 하이퍼미디어 제어 요소로, 다음 작업 단계나 관련 데이터 리소스를 탐색할 수 있게 한다.

 

주요 특징:

  • 데이터 요소 간의 명확한 관계를 정의하고, 클라이언트가 추가 요청을 수행할 수 있게 함.
  • 하이퍼미디어 패턴을 통해 클라이언트가 더 적은 정보로도 효율적으로 작업을 수행할 수 있게 함.
  • URI, URL 등을 사용해 명확한 데이터 참조를 제공.

 

포스 충돌:

  • 유연성 vs. 복잡성: 클라이언트가 다양한 경로를 탐색할 수 있게 하면 유연성이 높아지지만, 그만큼 메시지의 복잡성도 증가한다.
  • 명확성 vs. 성능: 링크를 사용하면 명확하게 데이터 간 관계를 표현할 수 있지만, 많은 링크는 페이로드 크기를 키워 성능 저하를 초래할 수 있다.
  • 보안 vs. 접근성: 링크를 통해 제공하는 데이터는 보안이 중요하지만, 쉽게 접근할 수 있게 하려다 보면 보안 취약점이 발생할 수 있다.

참고 문헌
[1]  올라프 짐머만 , 미르코 스토커 , 다니엘 뤼브케 , 우베 즈둔 , 세자레 파우타소 , "마이크로서비스 API 디자인 패턴: 쉬운 통합을 위한 결합도 최적화 전략" 에이콘. 이승범 역

[1]의 4장은 패턴 언어 개요를 다루고 있다. 여기서는 기본 메시지 구조 관련한 패턴에 대해 살펴 보자

 

1. 아토믹 파라미터 (Atomic Parameter)

  • 설명: API 메시지에서 사용되는 가장 기본적인 단위로, 단순한 비정형 데이터(예: 숫자, 문자열, 불리언 등)를 표현.
  • 주요 특징:
    • 메시지 교환의 기본 전송 단위로 사용.
    • 단일 값으로 명확하게 정의되어 있음.
    • 이름, 타입, 선택성 등을 명시하여 데이터의 의미를 전달.
  • 포스의 충돌:
    • 과도한 사용 시 API의 효율성이 떨어질 수 있음.
    • 단일 값만으로 표현할 수 없는 복잡한 구조의 데이터 요구에 대응하기 어려움​

2. 아토믹 파라미터 리스트 (Atomic Parameter List)

  • 설명: 여러 개의 아토믹 파라미터가 밀접하게 연관되어 있을 때 이를 하나의 그룹으로 결합해 표현하는 방식.
  • 주요 특징:
    • 관련된 데이터 엘리먼트를 논리적 그룹으로 묶음.
    • 클라이언트가 특정한 데이터 필드만 선택적으로 요청할 수 있도록 허용.
    • 리스트는 위치 인덱스 또는 키로 식별되며, 필요 시 반복적으로 사용할 수 있음.
  • 포스의 충돌:
    • 과도한 중첩으로 인해 데이터 파싱과 처리의 복잡도가 증가할 수 있음.
    • 특정 플랫폼에서 스칼라 값의 제한으로 인한 구현 문제 발생 가능.

3. 파라미터 트리 (Parameter Tree)

  • 설명: 아토믹 파라미터와 리스트만으로 표현할 수 없는 복잡한 데이터를 계층적 구조로 정의.
  • 주요 특징:
    • 복잡한 데이터 구조를 계층적으로 표현해 데이터의 포함 관계를 명확히 함.
    • 각 노드는 단일 아토믹 파라미터, 리스트, 또는 또 다른 트리로 구성될 수 있음.
    • 재귀적으로 정의되며, JSON 등에서 객체의 중첩 구조를 표현하는 데 유용.
  • 포스의 충돌:
    • 중첩 구조가 지나치게 복잡해지면 대역폭과 성능 저하 우려.
    • 복잡한 구조의 데이터 트리로 인해 API 간 상호운용성이 떨어질 수 있음.

4. 파라미터 포리스트 (Parameter Forest)

  • 설명: 여러 개의 파라미터 트리를 그룹화해 최상위 레벨에서 관리하는 패턴.
  • 주요 특징:
    • 여러 트리들을 하나의 구조로 결합하여 사용자가 필요한 데이터를 쉽게 참조 가능.
    • 다양한 파라미터 트리를 독립적으로 관리할 수 있도록 함.
    • 요청이나 응답 본문에서 복수의 파라미터 트리를 노출.
  • 포스의 충돌:
    • 복잡한 데이터 구조로 인해 직렬화와 역직렬화의 부담이 커질 수 있음.
    • 구조적 복잡성으로 인해 메시지 교환 시 불필요한 데이터 전송이 발생할 위험.

 

참고 문헌
[1]  올라프 짐머만 , 미르코 스토커 , 다니엘 뤼브케 , 우베 즈둔 , 세자레 파우타소 , "마이크로서비스 API 디자인 패턴: 쉬운 통합을 위한 결합도 최적화 전략" 에이콘. 이승범 역

[1]의 4장은 패턴 언어 개요를 다루고 있다. 여기서는 API 방향 및 가시성 관련한 패턴에 대해 살펴 보자

1. 프론트엔드 통합 (Frontend Integration)

  • 설명: 모바일 앱이나 웹 애플리케이션의 사용자 인터페이스를 백엔드 서비스와 연결하여 데이터를 교환하고 기능을 수행할 수 있게 해주는 패턴.
  • 주요 특징:
    • 주로 HTTP/REST API로 구현되며 클라이언트에서 백엔드로 요청을 전달.
    • 데이터 소스 및 프로세싱 로직을 프론트엔드에 제공.
    • 클라이언트가 백엔드 활동을 호출하거나 데이터를 업로드할 수 있도록 함.
  • 포스의 충돌:
    • 데이터의 적시성과 효율성을 유지하면서 요청의 페이로드 크기를 최적화해야 함.
    • 과도한 통신으로 인한 성능 저하와 클라이언트 오버페칭을 방지해야 함.

2. 백엔드 통합 (Backend Integration)

  • 설명: 시스템의 서로 다른 백엔드 컴포넌트 간에 데이터를 교환하고 상호작용을 트리거할 수 있게 하는 패턴.
  • 주요 특징:
    • 분산된 애플리케이션의 백엔드에서 데이터를 교환하고 활동을 트리거할 수 있도록 지원.
    • 비동기 메시징, HTTP, gRPC 등 다양한 기술로 구현 가능.
    • 클라이언트가 아닌 다른 백엔드 시스템에서 독점적으로 사용됨.
  • 포스의 충돌:
    • 시스템 간 상호 운용성을 유지하면서 독립적 개발이 가능하도록 해야 함.
    • 데이터 교환과 처리 속도를 균형 있게 조정해야 함.

3. 퍼블릭 API (Public API)

  • 설명: 공개적으로 제공되는 API로, 전 세계 누구나 접근할 수 있는 형태로 배포됨.
  • 주요 특징:
    • 공용 인터넷에 노출되며 사용자 인증 및 액세스 제어가 필요할 수 있음.
    • API 키 또는 인증 토큰을 통해 보안 유지.
    • 서비스 레벨 계약(SLA)과 요금제 등을 통해 경제적 모델을 구축.
  • 포스의 충돌:
    • 높은 보안성과 안정성을 제공하면서 사용자 접근성을 보장해야 함.
    • 공정한 요금제 설정과 과도한 API 사용 방지를 위한 제한 필요.

4. 커뮤니티 API (Community API)

  • 설명: 여러 조직이 공동으로 사용하는 API로, 특정 사용자 그룹에게만 제한된 접근을 허용하는 형태.
  • 주요 특징:
    • 제한된 네트워크(예: 엑스트라넷)를 통해 배포.
    • 특정 커뮤니티의 회원만 사용 가능.
    • 보안 및 커뮤니티 지원 관리가 중요.
  • 포스의 충돌:
    • 보안성과 사용 편의성을 동시에 만족해야 함.
    • 커뮤니티 회원들 간의 상호작용과 API 사용 정책을 일관되게 관리해야 함.

5. 솔루션 내부 API (Solution Internal API)

  • 설명: 동일한 애플리케이션 내에서 사용되는 API로, 내부 컴포넌트 간 통신을 위해 설계됨.
  • 주요 특징:
    • 마이크로서비스, 모듈 등 내부 시스템 컴포넌트 간 데이터 전송에 사용.
    • 로컬에서 실행되거나 동일한 데이터 센터 내에서 작동하는 서비스 간 통신을 지원.
    • 외부 노출 없이 내부에서만 사용됨.
  • 포스의 충돌:
    • 시스템 내에서 효율적인 통신을 유지하면서 데이터의 일관성을 보장해야 함.
    • 독립적 배포와 함께 복잡한 시스템의 결합성을 줄여야 함.

참고 문헌
[1]  올라프 짐머만 , 미르코 스토커 , 다니엘 뤼브케 , 우베 즈둔 , 세자레 파우타소 , "마이크로서비스 API 디자인 패턴: 쉬운 통합을 위한 결합도 최적화 전략" 에이콘. 이승범 역

 

[1]의 5장은 API 설계에서 엔드포인트와 동작을 정의하는 방법에 대한 내용을 다루고 있다. 엔드포인트의 설계는 API의 아키텍처에서 중요한 부분으로, 요청 및 응답 메시지의 구조뿐만 아니라 엔드포인트 배치와 동작도 고려해야 한다.
엔드포인트의 역할은 크게 데이터 지향(Information Holder)과 활동 지향(Processing Resource)으로 나뉜다.

활동 지향 엔드포인트 역할은는 계산, 상태 변경 등의 동작을 수행하며, 클라이언트가 원격으로 처리 작업을 요청할 수 있도록 한다. 데이터 지향 엔드포인트 역할은는 데이터의 읽기/쓰기 접근을 지원하며, 데이터의 수명 및 변경 가능성에 따라 다양한 유형으로 분류됩니다. 우선, 활동 지향 관련해서 처리 리소스 패턴들과  데이터 지향 관련해서는 정보 보유자 패턴으로 나누어 살펴 보자.

 

처리 리소스

처리 리소스와 관련된 패턴들은 주로 활동 지향 엔드포인트를 설계하는 데 사용된다. 이 패턴들은 API가 클라이언트로부터 요청을 받아 어떤 작업을 수행하거나 상태를 변경할 수 있게 하는데, 이를 통해 다양한 비즈니스 로직을 처리할 수 있다. 주요 패턴과 그 특징은 다음과 같다.

1. 계산 함수 (Computational Function)

설명: 입력 값을 받아 계산 작업을 수행하고, 그 결과를 반환하는 동작.

 

주요 특징:

  • 상태 비저장(stateless)으로 동작하며, 단순하거나 복잡한 연산 작업을 수행.
  • 클라이언트가 제공한 입력에 따라 예측 가능한 결과를 생성.
  • 연산의 반복 호출 시 일관된 결과를 보장.

포스 충돌:

  • 응답 시간 대 정확성: 빠른 계산을 위해 성능 최적화가 필요하지만, 정확성을 유지해야 함.
  • 표현력 대 단순성: 더 많은 계산 기능을 제공할수록 API가 복잡해지고 학습이 어려워질 수 있음.

2. 인출 동작 (Retrieval Operation)

설명: 데이터를 조회하여 클라이언트에게 반환하는 읽기 전용 작업.

 

주요 특징:

  • 안전한 읽기 작업으로 상태를 변경하지 않음.
  • 다양한 데이터 소스로부터 데이터를 집계하여 제공할 수 있음.
  • 멱등성 보장으로 같은 요청에 대해 항상 같은 결과 반환.

포스 충돌:

  • 확장성 대 일관성: 여러 클라이언트의 동시 요청에 대해 일관된 데이터를 빠르게 제공해야 함.
  • 캐싱 대 최신성: 캐싱을 사용하면 응답 속도를 높일 수 있지만, 데이터의 최신성을 보장하기 어려울 수 있음.

3. 상태 생성 동작 (State Creation Operation)

설명: 클라이언트 요청을 받아 새로운 리소스나 객체를 생성하는 작업.

 

주요 특징:

  • 쓰기 작업으로, 데이터를 생성하고 이를 시스템에 저장.
  • 생성된 리소스에 대한 ID나 참조를 반환하여 후속 작업에 사용 가능.
  • 입력 데이터의 유효성 검사가 필요.

포스 충돌:

  • 유효성 대 성능: 유효성 검사를 철저히 할수록 성능이 저하될 수 있음.
  • 데이터 중복 대 일관성: 동일한 요청을 반복 처리할 때 데이터 중복 생성 문제가 발생할 수 있음.

4. 상태 전이 동작 (State Transition Operation)

설명: 기존 리소스의 상태를 변경하거나 업데이트하는 작업.

 

주요 특징:

  • 읽기-쓰기 작업으로, 리소스의 상태를 업데이트하거나 수정.
  • 상태 변경에 대한 명확한 정의가 필요하며, 멱등성을 고려하여 반복 호출 시 결과가 일관되게 유지.
  • 예를 들어, 주문 상태를 "처리 중"에서 "배송 중"으로 전환.

포스 충돌:

  • 멱등성 대 복잡성: 상태 변경 작업의 멱등성을 보장하려면 복잡한 설계가 필요할 수 있음.
  • 성능 대 일관성: 빠른 상태 전환을 위해 비동기 처리를 사용하면 일관성을 유지하기 어려울 수 있음.

정보보유자

정보 보유자와 관련된 패턴들은 주로 데이터 지향 엔드포인트 설계에 사용된다. 이 패턴들은 API가 데이터를 클라이언트에게 제공하고, 필요에 따라 데이터를 읽고 쓰는 작업을 지원하도록 돕는다. 주요 패턴과 그 특징은 다음과 같다.

1. 운용 데이터 보유자 (Operational Data Holder)

설명: 일상적으로 자주 변경되는 데이터를 관리하며, 클라이언트가 데이터 생성, 읽기, 업데이트, 삭제(CRUD) 작업을 수행할 수 있도록 지원.

 

주요 특징:

  • 읽기-쓰기 작업을 지원하며, 실시간 데이터 처리가 중요한 경우 사용.
  • 짧은 수명의 데이터를 자주 업데이트하며, 빠른 응답과 처리 속도가 요구됨.
  • 예: 쇼핑몰의 주문 내역, 은행 계좌 거래 내역.

포스 충돌:

  • 속도 대 데이터 일관성: 빠른 데이터 처리가 중요하지만, 데이터 일관성을 유지해야 함.
  • 가용성 대 보안: 데이터를 자주 사용하고 접근할 수 있어야 하지만, 민감한 정보일 경우 보안 조치를 강화해야 함.

2. 마스터 데이터 보유자 (Master Data Holder)

설명: 상대적으로 안정적이고, 자주 변경되지 않는 주요 참조 데이터를 관리하는 리소스.

 

주요 특징:

  • 읽기 전용 또는 제한된 쓰기 작업을 지원하며, 주요 비즈니스 데이터를 안정적으로 제공.
  • 변경 빈도가 낮으며, 데이터의 일관성과 품질을 유지하는 데 중점.
  • 예: 고객 정보, 제품 카탈로그.

포스 충돌:

  • 일관성 대 성능: 데이터 일관성을 유지해야 하지만, 이를 위해 성능이 저하될 수 있음.
  • 확장성 대 최신성: 클라이언트의 확장성 요구에 따라 성능을 높이면서도, 데이터가 최신 상태임을 보장해야 함.

3. 참조 데이터 보유자 (Reference Data Holder)

설명: 국가 코드, 통화 코드 등 기본적이고 자주 변경되지 않는 참조 데이터를 제공하는 리소스.

 

주요 특징:

  • 읽기 전용으로 제공되며, 고정된 데이터를 여러 클라이언트가 참고할 수 있음.
  • 데이터 변경이 드물기 때문에 캐싱을 통해 빠른 응답이 가능.
  • 예: 언어 코드, 국가 및 지역 코드.

포스 충돌:

  • 최신성 대 캐싱 효율성: 캐싱을 사용하여 성능을 높이려 하지만, 데이터의 정확성과 최신성을 보장해야 함.
  • 보안 대 접근성: 특정 참조 데이터를 보안이 필요한 경우 접근 제한이 필요하지만, 동시에 다양한 클라이언트가 접근할 수 있어야 함.

4. 데이터 전송 리소스 (Data Transfer Resource)

설명: 클라이언트 간 데이터 공유 및 전송을 위한 임시 저장소 역할을 하는 리소스.

 

주요 특징:

  • 클라이언트가 데이터를 임시로 저장하고, 다른 클라이언트로 전송할 수 있음.
  • 단기 보유 및 관리로, 데이터를 저장한 후 일정 시간이 지나면 삭제하거나 이동.
  • 예: 파일 업로드/다운로드 서비스, 메일 서버의 큐.

포스 충돌:

  • 저장 기간 대 가용성: 데이터를 얼마나 오랫동안 보관할 것인지와 이를 쉽게 접근할 수 있도록 할 것인지 간의 균형.
  • 보안 대 효율성: 전송 데이터를 암호화하고 보호해야 하지만, 이를 처리하는 과정에서의 성능 저하를 방지해야 함.

 

5. 링크 조회 리소스 (Link Lookup Resource)

설명: 다른 정보 보유자 리소스로의 링크를 제공하며, 데이터 관계를 유지하고 탐색을 지원하는 리소스.

 

주요 특징:

  • 읽기 전용으로, 다른 리소스 간의 관계를 정의하고 참조를 관리.
  • 데이터 관계를 명확히 하여 클라이언트가 다른 리소스 간의 데이터 연결을 쉽게 탐색할 수 있게 함.
  • 예: 제품과 관련된 리뷰, 고객과 관련된 주문 내역.

포스 충돌:

  • 데이터 연결성 대 독립성: 여러 리소스를 연결해야 하지만, 각 리소스는 독립적으로 관리되어야 함.
  • 응답 시간 대 일관성: 빠르게 데이터 관계를 조회해야 하지만, 데이터의 일관성을 유지해야 함.

 

 

참고 문헌
[1]  올라프 짐머만 , 미르코 스토커 , 다니엘 뤼브케 , 우베 즈둔 , 세자레 파우타소 , "마이크로서비스 API 디자인 패턴: 쉬운 통합을 위한 결합도 최적화 전략" 에이콘. 이승범 역

[1]은 API 설계에 관한 심도 있는 가이드로, 1장에서는 API 설계에 필요한 기본 개념과 패턴을 다룹니다. 주요 내용은 다음과 같다.

API 기본 개념:
API(Application Programming Interface)가 무엇인지 설명하고, 현대 소프트웨어 아키텍처에서 API의 중요성을 강조한다. API 설계에서 자주 겪는 문제(결합도, 세분화 등)를 설명하고, API가 어떻게 기능을 노출하면서도 구현 세부 사항을 숨기는지 설명한다.

 

원격 API:
API가 서로 다른 서버나 지역에 분산된 애플리케이션 간의 통신을 어떻게 가능하게 하는지 다룬다. RPC, SOAP, REST와 같은 다양한 원격 API 기술이 등장한 역사와 발전 과정을 설명한다.

 

API 설계의 어려움과 패턴:
다양한 클라이언트의 요구를 충족시키면서 확장성과 유지보수가 가능한 API 설계의 어려움에 대해서 설명한다. API를 모듈화하고 유연성을 유지하면서도 호환성을 지키는 설계 전략을 제시한다.

 

아키텍처적으로 중요한 요구 사항:

1장에서는 다음과 같은 내용을 언급한다.

  • 이해 가능성: API의 요청 및 응답 메시지 구조는 이해하기 쉽고, 불필요한 복잡성을 피해야 한다. 이를 위해 API는 도메인 모델을 따르는 것이 좋다. 중요한 점은 내부 구현 세부 정보가 외부에 드러나지 않도록 해야 한다.
  • 정보 공유와 정보 숨기기: API 설계에서 중요한 것은 클라이언트가 필요로 하는 정보를 정의하면서도, 불필요한 세부 사항을 숨기는 것이다. 구현 세부 정보가 외부로 노출되면 API가 진화할 때 클라이언트에 부정적인 영향을 미칠 수 있다.
  • 결합도(Coupling): 느슨한 결합(Loose Coupling)은 API 설계에서 필수적인 품질 속성이다. API 클라이언트와 프로바이더가 서로 독립적으로 진화할 수 있도록 하는 것이 목표이다. 이를 위해 플랫폼 자율성, 시간 자율성, 형식 자율성 등의 요소를 고려하여 결합도를 최소화해야 한다.
  • 수정 가능성(Modifiability): API는 진화 과정에서 유연성을 유지해야 하며, 버전 관리와 호환성을 고려해 설계해야 한다. 기존 클라이언트의 동작에 영향을 주지 않으면서도 쉽게 수정될 수 있어야 한다.
  • 성능 및 규모 확장성: 네트워크 지연 시간과 대역폭 사용에 영향을 받는 클라이언트 응답 시간, 마샬링 및 언마샬링 등의 성능 문제가 중요한다. API의 처리량과 확장성은 더 많은 클라이언트를 지원하면서도 응답 시간을 저하시키지 않아야 한다.
  • 데이터 간결성: 성능과 보안을 위해 API는 필요 이상으로 많은 데이터를 주고받지 않도록 설계되어야 한다. API가 진화함에 따라 불필요한 데이터가 축적될 가능성이 크기 때문에, 데이터의 간결함을 유지하는 것이 중요하다.​

이러한 요구 사항들은 API 설계 및 운영에서 필수적인 품질 속성으로 간주되며, API가 성공적으로 작동하고 진화할 수 있도록 돕는다.

 

사례 연구와 의사 결정 모델:

보험 회사의 서비스 통합 사례를 통해 API 사용 사례를 다룬다. API 설계에서 의사 결정을 내릴 때 고려해야 할 모델과 설계 체크리스트를 제시한다.

 

고급 주제:

클라우드 네이티브 API, 마이크로서비스와 같은 최신 API 설계 방식이 확장성과 독립적인 배포에 어떻게 기여하는지 설명한다. API 버전 관리 및 시간이 지남에 따라 발생하는 변경 사항을 어떻게 처리할지에 대한 전략을 설명한다. 소프트웨어 아키텍트와 개발자들이 견고하고 확장 가능하며 통합이 용이한 API를 설계하는 데 필요한 지식을 제공한다.

 

참고 문헌
[1]  올라프 짐머만 , 미르코 스토커 , 다니엘 뤼브케 , 우베 즈둔 , 세자레 파우타소 , "마이크로서비스 API 디자인 패턴: 쉬운 통합을 위한 결합도 최적화 전략" 에이콘. 이승범 역

+ Recent posts