데이터 형식

API를 사용할 때(특히 REST API), 정보를 주고받는 형식은 표준을 따라야 하고 기계와 사람이 모두 읽을 수 있어야 한다.

대표적인 데이터 형식은 XML, JSON, YAML이다.

 

---

1. 왜 데이터 형식이 중요한가?

• 언어 도구나 라이브러리로 쉽게 변환 가능 → 데이터를 Python 리스트, 딕셔너리 같은 구조로 변환해 다루기 쉽다.
• 표준 형식이므로 서로 다른 시스템 간 호환성 확보.
• 문제 발생 시 직접 읽고 수정 가능 → 테스트 메시지 작성, 오류 메시지 검증.
• 잘못된 메시지 감지 → 전송 오류나 통신 문제를 빨리 파악할 수 있다.

 

2. REST API에서 자주 보이는 패턴

1. 인증: 사용자/비밀번호를 보내고, 만료 시간이 있는 토큰을 발급받음.
2. GET 요청: 리소스 상태를 XML/JSON/YAML 형식으로 가져옴.
3. 데이터 수정: 받은 XML/JSON/YAML을 수정.
4. POST/PUT 요청: 리소스 상태를 변경하고, 결과를 다시 XML/JSON/YAML로 확인.

 

3. XML (Extensible Markup Language)

• 태그 기반 구조 (<tag>데이터</tag>).
• 데이터는 트리 구조로 표현됨 (루트 태그, 부모-자식 관계).
• 장점: 오래된 표준이라 도구와 지원이 매우 많음.
• 단점: 사람이 읽기엔 다소 복잡하고, JSON/YAML에 비해 변환이 번거로움.

<?xml version="1.0" encoding="UTF-8"?>
<vms>
  <vm>
    <vmid>0101af9811012</vmid>
    <type>t1.nano</type>
  </vm>
  <vm>
    <vmid>0102bg8908023</vmid>
    <type>t1.micro</type>
  </vm>
</vms>

• 루트 태그 필요 (<vms> ... </vms>).
• 사용자 정의 태그 가능 → 의미를 잘 드러내는 이름 권장.
• 속성 사용 가능: <vm vmid="0101" type="t1.nano"/>
• 특수문자 처리 필요 (<, >, & 등은 엔터티 코드로 변환하거나 CDATA 블록 사용).

 

4. JSON (JavaScript Object Notation)

• 키:값 쌍 기반, Python 딕셔너리와 유사.
• 중괄호 {}는 객체(Object), 대괄호 []는 리스트(Array).
• 장점: 단순하고 가볍다, 파싱이 쉽다, 많은 언어에서 바로 사용 가능.
• 단점: 주석 불가.

{
  "edit-config": {
    "default-operation": "merge",
    "test-operation": "set",
    "some-integers": [2,3,5,7,9],
    "a-boolean": true,
    "more-numbers": [225.0, -1.0735]
  }
}

• 지원하는 데이터 타입: 숫자, 문자열, 불리언(true/false), null.
• 공백과 줄바꿈은 의미 없음 → 사람이 보기 좋게 정렬 가능.

 

5. YAML (YAML Ain’t Markup Language)

• JSON의 상위 호환, 사람이 읽기 쉽게 설계됨.
• 들여쓰기로 구조를 표현 (괄호, 태그 사용 안 함).
• Ansible, Kubernetes 설정 파일 등에서 많이 사용됨.

---
edit-config:
  a-boolean: true
  default-operation: merge
  more-numbers:
    - 225.0
    - -1.0735
  some-integers:
    - 2
    - 3
    - 5
    - 7
    - 9
  test-operation: set
...

• 들여쓰기 필수 (공백 2칸 권장, 탭 금지).
• 주석 지원 → # 사용.
• 여러 개의 문서 구분 가능 (---, ...).
• 긴 문자열 처리 가능 (> 접기, | 줄바꿈 유지).

6. 비교 정리

구분	XML	JSON	YAML
구조	태그 기반	키:값, 리스트	들여쓰기 기반
가독성	복잡	간단	가장 쉬움
주석	지원	미지원	지원
사용처	오래된 표준, NETCONF 등	API 응답, 웹 서비스	설정 파일, 자동화 도구

 

7. 핵심 요약

• API에서 데이터를 주고받을 때 XML, JSON, YAML이 표준.
• XML: 태그 기반, 도구 풍부하지만 무겁다.
• JSON: 가볍고 간단, 표준 API 형식으로 제일 많이 사용.
• YAML: JSON보다 더 읽기 쉬움, 설정/자동화에 강점.

 

8. HTTP 메서드 (GET, POST, PUT, DELETE)

• 웹에서 데이터 주고받는 표준 방식.
• REST API는 이 HTTP 메서드를 활용해서 장비 상태를 관리.

예시 (RESTCONF 기반):

GET /restconf/data/interfaces/interface=GigabitEthernet0/0

-> 장비에서 특정 인터페이스 상태 조회

 

PUT /restconf/data/interfaces/interface=GigabitEthernet0/0 { "enabled": true }

-> 인터페이스를 enable 상태로 변경

즉, HTTP 메서드 = "무슨 동작을 할 건지"를 나타내는 신호등.

• GET = 조회
• POST = 생성
• PUT = 수정
• DELETE = 삭제

 

9. RESTCONF와 NETCONF (네트워크 관리 프로토콜)

YANG 데이터 모델

• 네트워크 장비의 설정과 상태를 표현하는 공통 구조(설계도).
• RESTCONF와 NETCONF 모두 이 YANG 모델을 기반으로 동작한다는 점이 핵심.

YANG 개발 키트(YDK)

• 프로그래밍 언어(C++, Python 등)에서 사용할 수 있는 라이브러리로, 데이터 포맷(XML/JSON)을 내부적으로 다루기 쉽게 추상화 해준다.

RESTCONF

• HTTP/HTTPS 위에서 동작하는 네트워크 관리 프로토콜.
• 즉, RESTCONF는 REST API 스타일을 네트워크 장비 관리에 적용한 것.
• 데이터 포맷은 보통 JSON 또는 XML.
• REST API처럼 동작하며, RESTful 방식의 URI와 HTTP 메서드(GET, POST, PUT 등)를 통해 YANG 모델 데이터를 주고받음
• Cisco IOS-XE 같은 장비에서 RESTCONF 많이 지원.

NETCONF

• SSH 위에서 동작하는 네트워크 관리 프로토콜.
• 데이터 포맷은 XML만 사용.
• YANG 모델 구조를 RPC 메시지(<rpc>...</rpc>)로 표현하고, 이를 SSH를 통해 교환 & 처리
• 장비 구성(config)을 트랜잭션처럼 안정적으로 바꿀 수 있다.

RESTCONF vs NETCONF 비교

구분	RESTCONF	NETCONF
전송 기반	HTTP/HTTPS	SSH
데이터 포맷	XML, JSON	XML
접근 방식	REST API 스타일 (GET/POST/PUT)	RPC 스타일 (원격 프로시저 호출)
장점	웹 친화적, JSON 지원 → 가볍고 단순	안정적, 구성 변경에 강력 (트랜잭션 지원)
활용	장비 상태 조회/변경에 가볍게 사용	대규모 설정/구성 변경 시 안정성 확보

 

 

10. REST API (일반 개념) 와 RESTCONF (네트워크 관리 REST API)

1) REST API (일반 개념)

• REST(Representational State Transfer) 아키텍처 스타일을 기반으로 한 API.
• HTTP 메서드(GET, POST, PUT, DELETE 등)를 사용해서 리소스(Resource)에 접근.
• JSON, XML 등 표준 데이터 포맷으로 주고받음.
• 웹/모바일 개발, 클라우드 서비스 등 전 분야에서 광범위하게 사용됨.

2) RESTCONF (네트워크 관리 특화 REST API)

• IETF에서 정의한 네트워크 관리용 REST API 표준 (RFC 8040).
• 전송: HTTP/HTTPS
• 데이터 포맷: JSON 또는 XML
• 핵심 차이:
  • YANG 모델을 기반으로 데이터(장비 설정/상태)를 구조화.
  • 네트워크 장비의 설정(running-config)이나 상태(operational data)에 접근할 수 있는 명확한 리소스 구조가 정의되어 있음.
  • 단순한 “웹 API”가 아니라 “네트워크 장비 관리 전용 REST API”라는 점이 포인트.

 

11. Cisco IOS 계열 장비별 자동화 프로토콜 지원 정리

Cisco 장비는 OS 계열에 따라 Netmiko, REST API, RESTCONF, NETCONF 지원 여부가 달라진다. 

1) IOS (Internetwork Operating System)

• 설명: Cisco 전통적인 네트워크 OS. 주로 구형 라우터·스위치에 탑재.
• 구조: Monolithic (단일 구조).
• 장점: 단순하고 안정적.
• 단점: 프로세스 분리가 없어, 한 기능 장애가 전체 다운으로 이어질 수 있음.
• 사용 장비: Catalyst 2960/3750, ISR 1900/2900 등 구형 장비.

2) IOS XE

설명: 리눅스 기반 모듈형 OS. IOS 기능을 IOSd 프로세스로 실행.

구조: Modular (모듈형, 프로세스 분리).

장점:

• 프로세스 분리로 안정성 향상 (부분 장애만 발생).
• API(RESTCONF, NETCONF, gRPC) 지원 → 자동화/프로그램 연동 적합.
• 멀티코어 활용 가능.

단점: 구조가 복잡하고, 지원 장비 제한.

사용 장비: Catalyst 9000 시리즈, CSR1000v, ASR1000, ISR 4000.

3) NX-OS (Nexus Operating System)

설명: 데이터센터용 네트워크 OS. Nexus 스위치, MDS 스토리지 스위치에 탑재.

구조: 리눅스 기반, 모듈형.

장점:

• 대규모 데이터센터 환경에 최적화.
• vPC, FabricPath, VXLAN, EVPN 같은 최신 DC 기능 지원.
• API/자동화 친화적.

단점: Catalyst IOS 계열과 CLI 차이가 있어서 처음 접하면 낯설 수 있음.

사용 장비: Nexus 2000~9000, MDS 9000.

4) IOS XR (Internetwork Operating System eXtended Release)

설명: 서비스 프로바이더(통신사)급 라우터용 OS. 고가용성·확장성 중심.

구조: Microkernel 기반, 프로세스 완전 분리.

장점:

• 프로세스 독립 → 고장난 기능만 재시작 가능.
• 매우 높은 안정성과 확장성.
• 대규모 BGP/ISIS/MPLS, Segment Routing 등 지원.

단점: CLI 구조가 IOS와 달라 러닝커브가 있음.

사용 장비: ASR 9000, NCS 시리즈 (통신사 백본/코어 라우터).

5) ASA OS (Adaptive Security Appliance OS)

• 설명: Cisco ASA 방화벽에 탑재된 보안 OS.
• 구조: 전통적 CLI 기반.
• 장점: 방화벽/VPN 기능에 최적화.
• 단점: 최신 자동화 지원은 제한적.
• 사용 장비: ASA 5500-X 시리즈, ASAv(가상).

6) FTD (Firepower Threat Defense)

• 설명: ASA 기능 + 차세대 방화벽(NGFW, IPS, URL filtering 등) 기능 통합 OS.
• 구조: 리눅스 기반, GUI/정책 중심 관리 (FMC, Firepower Management Center).
• 장점: 차세대 보안 기능 강화.
• 단점: CLI보다 GUI 위주라 전통 네트워크 엔지니어에겐 낯설 수 있음.
• 사용 장비: Firepower 1000/2100/4100/9300, FTDv.

 

종합 요약 표

OS	계열대표	NETMIKO	REST API	RESTCONF	NETCONF
IOS	ISR, 구형 Catalyst	O	X	X	△ (일부)
IOS XE	ISR 4000, ASR1000, Cat9K	O	O	O	O
IOS XR	ASR9000, NCS	O	O (일부)	O	O
NX-OS	Nexus 9000, 7000	O	O (NX-API)	△ (제한)	O
ASA/FTD	ASA 방화벽, Firepower	O	O (전용 REST)	X	X