API 통합 예 : 설명, 개념, 예제

API 통합에 대해 배우고 더 자세히 알고 싶으십니까? 여기 API에서 API에 이르는 모든 것과 그 사이의 모든 부분을 보여주는 API 통합 사례가 있습니다.

API 통합은 한 시스템이 API(애플리케이션 프로그래밍 인터페이스)를 사용하여 시스템에 안전하게 액세스하는 동안 다른 시스템과 데이터를 전송하거나 다른 시스템에서 데이터를 전송할 수 있는 코드입니다. 일부 API 통합은 통합의 한 쪽에만 API가 있을 수 있는 반면 다른 API는 두 개 이상을 사용할 수 있습니다.

개발자들은 다양한 이유로 API 통합을 구축하지만, 이러한 통합은 일반적으로 다음 두 가지 범주 중 하나로 분류됩니다:

• 이들은 내부 비즈니스 워크플로우를 자동화하기 위해 회사 내부에서 실행됩니다.
• 외부 데이터 공유를 위해 서로 다른 회사의 시스템을 연결하기 위한 것입니다.

 

고객이 사용하는 다른 시스템에 제품을 연결하는 네이티브 통합을 만들어야 하는 소프트웨어 회사와 협력하기 때문에 이 예제에서는 외부 데이터 공유 시나리오를 다루겠지만, 이 개념은 내부 통합에도 적용됩니다.

• 통합 비즈니스 요구사항(이유).
• 통합 기술 요구사항(무엇).
• 실행을 위한 통합 세부 정보(방법).

 

 

API 통합 예 : 설명, 개념, 예제

 

 

통합 비즈니스 요구사항

이 API 통합 예제의 경우, 귀사는 건물 보안을 모니터링하기 위한 SaaS 제품을 제공합니다. 무엇보다도, 당신의 앱은 정기적으로 각 고객 건물의 중요한 지점에 설치된 센서의 온도와 습도 수준을 기록합니다. 고객은 이러한 온도 및 습도 값을 매일 제품에서 건물 유지보수 앱(StructManager)으로 내보내기 위해 통합이 필요합니다. 그런 다음 고객은 온도 및 습도 수준과 계획되지 않은 유지 관리 티켓 사이에 상관 관계가 있는지 여부를 확인합니다.

 

 

통합 기술 요구사항

통합을 구축할 때는 기술 요구사항부터 시작해야 합니다. 다음은 시작하기 전에 대답해야 할 기본 질문입니다:

• 어떤 데이터가 전송됩니까? (데이터)
• 단방향 통합입니까, 양방향 통합입니까? (방향)
• 통합이 얼마나 자주 실행됩니까? (주파수)
• 어떤 API가 사용됩니까? (API)
• 어떤 전송 프로토콜이 사용됩니까? (프로토콜)
• 어떤 전송 언어가 사용됩니까? (언어)
• 인증은 어떻게 처리됩니까? (작성)

 

API 통합 예제를 위해 다음을 모두 작성해 보겠습니다:

• 데이터: 전날(24시간)의 건물당 습도 및 온도 기록.
• 방향: 제품에서 StructManager로 단방향 내보내기.
• 빈도: 현지 시간으로 하루에 한 번 오전 7시에 건물을 짓습니다.
• API: 제품은 SOAP API를 사용합니다. StructManager는 REST API를 사용합니다.
• 프로토콜: 두 API 모두 HTTP를 지원합니다.
• 언어: 제품이 SOAP XML을 출력합니다. StructManager는 JSON을 입력으로 수락합니다.
• Auth: SOAP API 및 REST API는 OAuth를 사용합니다.

 

또한 습도 데이터는 상대 습도의 백분율로 제공되지만(두 앱 모두 동일) 제품의 온도 데이터는 섭씨를 사용하는 반면 Struct Manager는 화씨를 사용하도록 설정됩니다. 마지막으로 온도 및 습도 데이터는 제품에서 분당 한 번씩 수집되지만 Struct Manager는 15분마다 값을 알면 됩니다.

이 API 통합 예제에서는 두 개의 API, 두 개의 데이터 형식, 두 개의 온도 값 척도, 필요 이상의 데이터가 있습니다. 한 API에서 데이터를 가져와 다른 API로 넘겨주는 것 이상의 작업이 필요할 것 같습니다.

 

 

실행을 위한 통합 세부 정보

현지 시간으로 오전 7시에 통합 트리거를 통해 통합은 제품의 SOAP API로 지난 24시간 동안 건물당 지정된 고객에 대한 기록을 요청하는 쿼리를 전송합니다. 고맙게도 SOAP API는 연결 문자열에 내장된 OAuth를 지원합니다. SOAP API는 요청을 수신하면 일치하는 모든 레코드와 함께 HTTP를 통해 XML을 다시 보냅니다.

SaaS 제품에서 보낸 단일 레코드는 다음과 같습니다:

<environmental>
    <customer_id>AA8312</customer_id>
    <building_id>H265<building_id/>
    <sensor_id>1323</sensor_id>
    <sensor_loc>5W2NAB</sensor_loc>
    <timestamp>10:30</timestamp>
    <temperature>27.3</temperature>
    <humidity>55</humidity>
</environmental>

 

 

통합은 먼저 XML에서 JSON으로 모든 것을 변환하는 데이터 형식 변환을 수행하여 단일 레코드에 대해 다음과 같은 패턴을 제공합니다:

{
"environmental": {
    "customer_id": "AA8312",
    "building_id": "H265",
    "sensor_id": 1323,
    "sensor_loc": "5W2NAB",
    "timestamp": "10:30",
    "temperature": 27.3,
    "humidity": 55
    }
}

 

 

단일 건물에 30개의 센서가 분산되어 있는 샘플 고객의 경우 SOAP API에서 매일 내보내는 레코드는 43,200개가 포함되지만 통합을 통해 StructManager로 2,880개만 보내면 됩니다.

결과적으로 43,200개의 레코드를 필터링하고 타임스탬프 값이 hh:00, hh:15, hh:30 및 hh:45 패턴과 일치하지 않는 모든 레코드를 제거하기 위해 통합이 필요합니다. 그리고 예, 우리는 애초에 SOAP API에서 이러한 기록만 요청할 수 있는 방법을 찾을 수 있었지만, 이 경우에는 데이터의 상위 집합을 가져와서 거기서 수행하는 것이 더 깨끗합니다.

축소된 데이터 세트에 보관할 레코드만 포함된 경우, 약간의 간단한 계산을 사용하여 온도 값을 섭씨에서 화씨로 변환하기 위해 통합이 데이터에 한 번 더 반복되어야 합니다. 이제 샘플 데이터가 StructManager에서 가져오는 형식과 일치합니다:

{
"environmental": {
    "customer_id": "AA8312",
    "building_id": "H265",
    "sensor_id": 1323,
    "sensor_loc": "5W2NAB",
    "timestamp": "10:30",
    "temperature": 81.1,
    "humidity": 55
    }
}

 

 

이 시점에서 JSON으로 인코딩된 모든 2,880 레코드는 StructManager REST API에 대한 HTTP 요청으로 마무리됩니다. 다시 한번, 통합은 데이터를 제출하기 전에 OAuth를 사용하여 API와 연결합니다.

API 통합 예제는 성공적으로 실행되었으며 다음 실행을 위해 내일 오전 7시까지 기다리겠습니다.

 

 

추가 API 통합 리소스

물론, API 통합만큼 복잡한 주제를 제대로 수행할 수 있는 예는 거의 없습니다. 이를 염두에 두고 API 통합 개념에 대한 이해를 높이는 데 도움이 되는 몇 가지 리소스가 있습니다:

• 기술별 API(REST, XML-RPC, SOAP 및 GraphQL).
• 액세스 유형(개인, 파트너, 공용 및 개방형)별 API.
• 통합 전송 프로토콜 및 전송 언어.
• 통합 미디어 유형(이전에는 MIME 유형이라고 함).
• 통합의 중간에서 일어나는 일.

 

 

툴에 대한 모든 것

API는 SaaS 제품 간의 데이터 통합을 구축하는 데 매우 유용합니다. 그러나 이러한 API를 사용할 수 있는 올바른 툴을 확보하는 것은 매우 중요합니다. 인앱 통합을 제공하는 소프트웨어 회사로서, 이러한 툴은 고객의 요구를 충족하는 최소한의 통합 구현과 SaaS 제품의 상당 부분을 차지하는 통합 구현 간의 차이가 될 수 있으며, 이는 고객이 제품이 어디서 중단되고 통합이 시작되는지 알 수 없는 차이입니다. 이러한 툴 중 하나가 내장된 통합 플랫폼입니다.