제5장

2단계 - API 인터페이스 (센서 네트워크 API)

생태계 모니터링 데이터에 대한 프로그래밍 방식 접근을 가능하게 하는 RESTful API와 실시간 API

API 표준 개요

애플리케이션 프로그래밍 인터페이스(API)는 현대 모니터링 시스템을 서로 잇는 결합 조직이다. WIA 표준의 2단계는 생태계 데이터에 대한 프로그래밍 방식 접근을 가능하게 하는 포괄적인 API 명세를 정의하며, 자동화된 워크플로, 실시간 대시보드, 분석 파이프라인, 시스템 통합을 지원한다. 1단계가 데이터 형식을 표준화한다면, 2단계는 그 데이터에 접근하고 질의하고 전송하는 방식을 표준화한다.

WIA API 표준은 단순성과 폭넓은 호환성을 위해 RESTful 설계 원칙을 채택하는 한편, 센서 네트워크를 위한 실시간 스트리밍 기능을 추가한다. 이러한 혼합 방식은 연구에서 흔히 쓰이는 일괄(batch) 데이터 접근 패턴과, 운영 모니터링에 필수적인 연속 데이터 스트림을 모두 지원한다.

RESTful API 아키텍처

WIA REST API는 업계 표준 HTTP 메서드와 상태 코드를 따르므로 개발자에게 곧바로 익숙하면서도, 모니터링에 특화된 기능을 제공한다.

핵심 엔드포인트

엔드포인트메서드용도예시
/observationsGET종 관찰 기록 질의GET /observations?taxon=Ursus+arctos
/observationsPOST새 관찰 기록 제출POST /observations
/observations/{id}GET특정 관찰 기록 조회GET /observations/OBS-2025-001
/sensorsGET사용 가능한 센서 목록 조회GET /sensors
/sensors/{id}/dataGET센서 시계열 데이터 조회GET /sensors/TEMP-001/data?aggregation=hourly
/sitesGET모니터링 지점 질의GET /sites?bbox=-122.5,47.5,-122.0,48.0
/datasetsGET사용 가능한 데이터셋 탐색GET /datasets

질의 매개변수

모든 엔드포인트의 기준 URL은 https://api.{domain}/v1/ 형태이다. 2단계 명세가 GET /observations에 대해 정의한 질의 매개변수는 다음과 같다.

센서 시계열 엔드포인트 GET /sensors/{id}/data는 start_time, end_time, aggregation("raw", "hourly", "daily", "monthly"), format("json", "csv", "netcdf")을 받는다. 반경 검색, 정렬, 품질 하한(quality_min) 같은 추가 필터는 구현이 선택적으로 제공할 수 있는 확장이며, 명세의 기본 매개변수와 이름이 겹치지 않게 정의하고 OpenAPI 문서에 명시해야 한다.

API 요청 예시

GET /api/v1/observations?
    taxon=Haliaeetus+leucocephalus&
    start_date=2025-01-01&
    end_date=2025-12-31&
    bbox=-123.0,47.0,-122.0,48.0&
    quality_min=0.8&
    limit=100&
    format=json

Authorization: Bearer YOUR_API_KEY
Accept: application/json

응답 형식

모든 API 응답은 메타데이터, 데이터, 페이지 정보를 담은 일관된 구조를 따른다.

{
  "status": "success",
  "api_version": "1.0",
  "request_id": "req-12345",
  "timestamp": "2025-12-26T15:30:00Z",
  "query": {
    "taxon": "Haliaeetus leucocephalus",
    "start_date": "2025-01-01",
    "end_date": "2025-12-31",
    "bbox": "-123.0,47.0,-122.0,48.0"
  },
  "pagination": {
    "total_records": 342,
    "returned_records": 100,
    "page": 1,
    "total_pages": 4,
    "next_page": "/api/v1/observations?page=2&..."
  },
  "data": [
    {
      "record_id": "OBS-2025-001",
      "timestamp": "2025-03-15T10:30:00Z",
      "taxon": {...},
      "location": {...},
      ...
    },
    ...
  ]
}

인증과 권한 부여

생태계 모니터링 데이터에서 보안은 무엇보다 중요하다. 민감한 종의 위치를 보호하면서도 적절한 접근은 허용해야 하기 때문이다. WIA는 여러 인증 방식을 지원한다.

API 키

요청 헤더에 API 키를 담아 전달하는 단순한 인증 방식이다: Authorization: Bearer YOUR_API_KEY. 서버 간 통신과 스크립트 기반 접근에 적합하다.

OAuth 2.0

사용자 인증, 범위가 지정된 권한, 토큰 갱신을 지원하는 업계 표준 권한 부여 프레임워크이다. 세분화된 접근 제어가 필요한 웹 애플리케이션과 서비스에 적합하다.

JWT 토큰

JSON 웹 토큰(JWT)은 사용자 신원과 권한에 관한 클레임을 토큰 안에 담아 무상태(stateless) 인증을 가능하게 한다. 분산 시스템과 마이크로서비스 아키텍처에 유용하다.

접근 제어

2단계 명세는 인증 방식만 규정하고 접근 등급 체계는 구현에 맡긴다. 실무에서는 세분화된 권한을 통해 사용자가 접근하고 수정할 수 있는 데이터를 제어하며, 다음과 같은 등급 구성이 흔히 쓰인다.

실시간 스트리밍 API

센서 네트워크는 연속적인 데이터 스트림을 생성하므로 일괄 질의와는 다른 접근 패턴이 필요하다. WIA는 WebSocket과 MQTT 프로토콜을 사용하는 실시간 스트리밍 API를 제공한다.

WebSocket 연결

WebSocket은 양방향 통신 채널을 제공하여 서버에서 클라이언트로 데이터를 실시간으로 푸시할 수 있게 한다. 애플리케이션은 지속 연결을 수립하고, 센서 업데이트가 발생하는 즉시 이를 수신한다.

// 클라이언트 측 JavaScript 예시
const ws = new WebSocket('wss://api.example.org/stream');

ws.onopen = () => {
  // 특정 센서 구독
  ws.send(JSON.stringify({
    action: 'subscribe',
    sensors: ['TEMP-001', 'TEMP-002'],
    filters: {
      quality_min: 0.8
    }
  }));
};

ws.onmessage = (event) => {
  const data = JSON.parse(event.data);
  console.log('새 센서 측정값:', data);
  updateDashboard(data);
};

IoT 기기를 위한 MQTT

MQTT(Message Queuing Telemetry Transport)는 대역폭과 전력이 제한된 IoT 기기에 적합한 경량 발행-구독(publish-subscribe) 프로토콜이다. 센서는 토픽에 데이터를 발행하고, 구독자는 업데이트를 수신한다.

# 토픽 구조
sensors/{sensor_id}/data
sensors/{sensor_id}/status
sensors/{sensor_id}/alerts

# MQTT 발행 예시
Topic: sensors/TEMP-001/data
Payload: {
  "timestamp": "2025-12-26T15:30:00Z",
  "value": 12.3,
  "unit": "celsius",
  "qc_flag": "good"
}

# 종 관찰 토픽
observations/{site_id}/species

QoS 수준은 0(최대 한 번), 1(최소 한 번), 2(정확히 한 번)를 쓴다. 명세는 일반 데이터에는 QoS 1을, 중요 경보에는 QoS 2를 권장한다. WebSocket 데이터 메시지도 같은 형태로 "type": "sensor_reading", sensor_id, timestamp, value, unit, qc_flag를 담는다.

대량 데이터 접근

대규모 분석에는 개별 API 질의를 넘어서는 효율적인 대량 데이터 접근이 필요하다. WIA는 여러 가지 대량 접근 패턴을 지원한다.

비동기 질의

결과 집합이 큰 질의의 경우, 클라이언트가 요청을 제출하면 비동기로 처리된다. API는 작업 ID를 반환하며, 클라이언트는 완료 여부를 주기적으로 확인(폴링)하다가 준비되면 결과를 내려받는다.

POST /api/v1/bulk-query
{
  "query": {
    "dataset": "all-observations",
    "start_date": "2020-01-01",
    "end_date": "2025-12-31",
    "format": "csv"
  }
}

Response:
{
  "job_id": "bulk-123",
  "status": "queued",
  "estimated_time": "300 seconds",
  "status_url": "/api/v1/jobs/bulk-123"
}

# 상태 확인
GET /api/v1/jobs/bulk-123

# 준비되면 내려받기
GET /api/v1/jobs/bulk-123/download

데이터 덤프

질의 없이 내려받을 수 있도록 미리 생성해 둔 데이터셋이 /dumps/ 경로에 제공된다.

데이터셋갱신 주기
당해 연도 관찰 기록매일
센서 데이터매시간
전체 아카이브매월

파일 형식과 크기는 운영 기관과 보유 데이터에 따라 달라지므로 명세가 고정하지 않는다. 다중 레코드 파일은 제4장의 파일 형식 규약(NDJSON, gzip 압축 권장)을 따르는 것이 좋다.

데이터 제출 API

WIA API는 데이터 조회뿐 아니라 데이터 제출도 지원하여, 기여자가 관찰 기록과 센서 데이터를 업로드할 수 있게 한다.

단일 관찰 기록 제출

POST /api/v1/observations
Content-Type: application/json
Authorization: Bearer YOUR_API_KEY

{
  "wia_version": "1.0",
  "schema_type": "species-observation",
  "timestamp": "2025-12-26T14:00:00Z",
  "taxon": {...},
  "location": {...},
  ...
}

Response (201 Created):
{
  "status": "success",
  "record_id": "OBS-2025-12345",
  "validation": {
    "passed": true,
    "quality_score": 0.95
  }
}

일괄 제출

효율을 위해 여러 관찰 기록을 한 번에 제출한다. 명세에서 POST /observations는 단일 객체와 배열을 모두 받으므로, 별도의 일괄 제출 엔드포인트 없이 같은 엔드포인트에 레코드 배열을 보낸다. 응답에는 생성된 ID와 레코드별 검증 결과가 담긴다. 한 번에 보내는 레코드 수는 제4장의 권장 한도(파일당 10,000건)를 넘지 않는 것이 좋다.

POST /api/v1/observations
Content-Type: application/json
Authorization: Bearer YOUR_API_KEY

[
  {...관찰 기록 1...},
  {...관찰 기록 2...},
  {...관찰 기록 3...}
]

Response:
{
  "status": "success",
  "submitted": 3,
  "accepted": 3,
  "rejected": 0,
  "results": [
    {"record_id": "OBS-001", "status": "accepted"},
    {"record_id": "OBS-002", "status": "accepted"},
    {"record_id": "OBS-003", "status": "accepted"}
  ]
}

오류 처리

명확한 메시지를 갖춘 견고한 오류 처리는 개발자가 문제를 진단하고 해결하는 데 도움이 된다. 오류 응답은 다음과 같은 공통 구조를 따른다.

{
  "status": "error",
  "error_code": "INVALID_PARAMETER",
  "message": "사람이 읽을 수 있는 오류 설명",
  "details": { },
  "request_id": "req-12345",
  "timestamp": "2025-12-26T15:30:00Z"
}

명세가 사용하는 HTTP 상태 코드는 다음과 같다.

HTTP 상태의미예시
200 OK요청 성공데이터가 정상적으로 반환됨
201 Created리소스 생성됨관찰 기록이 제출됨
400 Bad Request잘못된 요청필수 필드 누락
401 Unauthorized인증 필요유효하지 않은 API 키
403 Forbidden접근 거부권한 부족
404 Not Found리소스가 존재하지 않음관찰 기록 ID를 찾을 수 없음
429 Too Many Requests요청 한도 초과API 호출 속도를 낮출 것
500 Internal Server Error서버 오류데이터베이스 사용 불가

요청 한도 제한

공정 사용 정책은 남용을 막으면서 서비스 가용성을 보장한다.

요청 한도 헤더는 클라이언트에게 현재 상태를 알려 준다.

X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 847
X-RateLimit-Reset: 1735228800

API 버전 관리

API는 시간이 지나며 발전한다. WIA는 URL 기반 버전 관리를 사용하여 하위 호환성을 보장하면서도 혁신을 가능하게 한다.

https://api.example.org/v1/observations
https://api.example.org/v2/observations

지원 중단(deprecation)이 결정된 버전도 최소 12개월 동안 계속 지원한다. 이 기간에 클라이언트는 새 버전으로 이전할 수 있다.

문서화와 개발자 도구

포괄적인 문서와 도구는 통합을 가속한다.

OpenAPI 명세

기계가 읽을 수 있는 API 명세는 도구의 자동 생성을 가능하게 한다. WIA 구현은 완전한 OpenAPI 3.0 명세를 https://api.{domain}/openapi.json에 게시하며, 여기에 엔드포인트 문서, 요청/응답 예시, 검증 스키마가 담긴다.

SDK와 클라이언트 라이브러리

2단계 명세(§6)는 공식 클라이언트 라이브러리의 패키지 이름을 다음과 같이 지정한다. 이 판 기준으로 아직 공개되지 않았으므로, 그 전까지는 REST API를 직접 호출하거나 저장소 api/typescript 디렉터리의 참조 TypeScript SDK 소스에서 출발한다.

대화형 문서

웹 기반 API 탐색기를 사용하면 코드를 작성하지 않고도 브라우저에서 직접 엔드포인트를 시험할 수 있다. 개발자는 질의를 실험하고, 응답을 확인하고, 코드 예시를 생성할 수 있다.

📝 장 요약

핵심 요점:

  • 2단계는 RESTful 인터페이스와 실시간 인터페이스를 통해 생태계 모니터링 데이터에 대한 프로그래밍 방식 접근을 가능하게 하는 포괄적인 API 명세를 제공한다
  • RESTful API는 업계 표준 HTTP 메서드와 상태 코드를 따르면서 다양한 질의, 필터링, 페이지 나누기를 지원한다
  • WebSocket과 MQTT를 통한 실시간 스트리밍은 연속적인 데이터 공급이 필요한 센서 네트워크와 운영 모니터링을 지원한다
  • API 키, OAuth 2.0, JWT를 포함한 인증 방식은 세분화된 권한과 함께 안전한 접근을 보장한다
  • 포괄적인 문서, OpenAPI 명세, 명세가 지정한 클라이언트 라이브러리 이름(아직 미공개)은 통합 장벽을 낮춘다

복습 질문:

  1. RESTful API는 생태계 모니터링 데이터 접근에 어떤 이점을 제공하는가?
  2. 실시간 스트리밍 프로토콜은 일괄 질의 API와 어떻게 다르며, 각각 언제 적합한가?
  3. 생태 데이터에서 인증과 권한 부여가 중요한 이유는 무엇이며, WIA는 어떤 방식을 지원하는가?
  4. 대량 데이터 접근 패턴은 개별 질의로는 지원할 수 없는 대규모 분석을 어떻게 가능하게 하는가?
  5. SDK와 클라이언트 라이브러리는 API 도입을 가속하는 데 어떤 역할을 하는가?
  6. API 버전 관리는 혁신과 하위 호환성 사이의 균형을 어떻게 맞추는가?

다음 장 예고:

제6장에서는 신뢰할 수 있는 센서 네트워크 통신, 품질이 보증된 데이터 수집, 검증된 측정을 보장하는 3단계 프로토콜 명세를 살펴본다.