<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=939333007162424&amp;ev=PageView&amp;noscript=1">

REST API의 정의와 Genian NAC 적용

안녕하세요
기술연구소 NAC 웹 파트 개발자 한동선입니다.
Genian NAC는 다양한 연동을 위해 Genian API 등을 제공해 왔었는데요.

최근 서비스/어플리케이션 개발의 흐름이 프론트엔드와 백엔드로 나누어지고 멀티 플랫폼, 멀티 디바이스로

넘어옴에 따라 다양한 환경에서의 지원이 필요하게 되었습니다.

따라서 Genian NAC에서도 이에 대응하기 위해 REST API를 제공하게 되었고 이번 블로그에서는 간략하게

REST API의 정의와 Genian NAC 에서는 REST API를 어떻게 제공하고 사용할 수 있는지에 대하여

알아보고자 합니다.

REST API란 무엇인가?

REST는 Representational State Transfer의 약자로 월드 와이드 웹과 같은 분산 하이퍼미디어 시스템을 위한

소프트웨어 아키텍처의 한 형식입니다.

이 용어는 HTTP 주요 저자 중 한 사람인 Roy Fielding에 의해 2000년 박사학위 논문에 소개되었습니다.

당시 웹(HTTP) 설계의 우수성에 비해 제대로 활용되지 않는 것에 안타까워하며 웹의 장점을 최대화할 수 있는

아키텍처로써 REST를 발표했다고 합니다.

REST는 HTTP 프로토콜을 의도에 맞게 활용하여 디자인하도록 유도하고 있기 때문에 디자인 기준이 명확해지며,

의미적인 범용성을 지니고 있어 중간 계층의 컴포넌트들이 서비스를 최적화하는데 도움이 됩니다.

REST의 기본 원칙을 성실히 지킨 서비스 디자인을 RESTful한 디자인이라고 말하며 Genian NAC의 REST API도 RESTful 하도록 디자인되고 있습니다.

REST의 구성

REST는 크게 세 가지로 구성할 수 있습니다.

•자원(Resource) - URI

•자원에 대한 행위 - HTTP METHOD

•자원에 대한 행위의 내용 정의(Representations) - HTTP Message Pay Load

1) HTTP Method

HTTP에는 여러 가지 메소드가 있지만 REST에서는 CRUD에 해당하는 (Create, Read, Update, delete) 4가지의 메소드만을 사용합니다.

Idempotent(멱등성)은 여러 번 수행해도 결과가 같은 경우를 의미합니다. POST(생성)와 같은 메소드는 리소스를 추가하기 때문에 Idempotent 하지 않지만 그 외 메소드는 반복 수행해도 Idempotent 합니다.

 

2) REST의 Resource

REST는 모든 개체가 리소스이며 이 리소스를 명사로 표현합니다. 각 세부 리소스에는 ID를 붙입니다.

예를 들어 특정 사용자를 조회하는 REST API는 아래와 같습니다.

•     GET   /users/andy

리소스는 크게 Collection 과 Element 단위로 나누어 표현할 수 있으며 한 자원의 집합(다수)을 Collection이라면 Element는 해당 집합의 한 객체라고 볼 수 있습니다.

REST의 특성 및 제한조건

1) Uniform (유니폼 인터페이스)

HTTP 표준에 따른다면 어떠한 기술이든지 사용할 수 있는 인터페이스입니다.

2) Stateless (무상태성)

클라이언트의 컨텍스트를 서버 쪽에서 유지(저장) 하지 않음을 의미합니다. API 요청만을 처리하므로 서버에서는 불필요한 정보를 관리하지 않음으로써 구현이 단순해집니다.

3) Cacheable (캐시 가능)

기존 웹 표준을 사용하기 때문에 웹에서 사용하는 기존 인프라 그대로 사용 가능합니다. HTTP 프로토콜 표준에서 사용하는 Last-Modified 태그나 E-Tag를 이용하면 캐싱 구현이 가능합니다.

4) Self-descriptiveness (자체 표현 구조)

API 내용만으로 별도의 문서 없이 쉽게 이해가 가능한 구조입니다.

5) Client-Server 구조

REST 서버는 API를 제공, 클라이언트는 사용자 인증 및 컨텍스트를 직접 관리하는 구조로 역할이 구분되기 때문에 서버/클라이언트 간 개발할 내용이 명확해지고 의존성이 줄어들게 됩니다.

6) 계층형 구조

REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고, 마이크로 서비스 아키텍처의 API Gateway나 Proxy 와 같은 네트워크 기반의 중간 매체를 사용할 수 있습니다.

Genian NAC REST API

앞서 소개한 것처럼 Genian NAC의 REST API는 RESTful 하게 디자인되고 개발되고 있습니다.

아직은 모든 기능이 API로 제공되어 있자는 않고 필요에 의해 하나씩 만들어지고 있지만 신규 기능의 경우에는

REST API로 처리되도록 개발이 되고 있고 계속해서 추가될 예정입니다.

 

SWAGGER

API 문서화를 위해 SWAGGER (http://swagger.io/) 를 이용하고 있습니다. SWAGGER는 REST API 문서화를

웹으로 보여주고 실제로 API를 호출할 수 있는 도구입니다.

이 도구를 이용하여 어떠한 API가 있는지 확인하고 테스트를 통해 어떻게 동작을 하는지를 알 수 있습니다.

접속을 하기 위해선 먼저 Genian NAC 웹 콘솔에 로그인을 해야 하며

https://centerip/mc2/swagger/index.html 의 경로를 통해 SWAGGER에 접속할 수 있습니다.


[Genian NAC에 추가한 SWAGGER 화면]

인증

SWAGGER를 통해 API를 테스트해 볼 수 있지만 이기종 혹은 다른 시스템에서 해당 API를 이용하기 위해선 인증을

해야만 이용할 수 있습니다. Genian NAC에서는 두 가지 방법으로 API를 이용할 수 있습니다.

1) Session

일반 웹 브라우저에서 로그인하는 것과 동일하게 세션 REST API를 이용하여 세션을 생성/조회/삭제를 할 수 있습니다. Genian NAC에 등록된 관리자로 Session API를 이용하여 세션을 생성한 후 세션을 생성한 관리자의 권한이

있는 API를 호출하여 사용할 수 있습니다.


[SWAGGER를 이용하여 SESSION REST API 호출]

2) API Key

Genian NAC의 관리자마다 API Key를 생성할 수 있습니다. 생성한 API Key를 이용하여 API를 호출하면 등록된 관리자와 동일한 권한으로 API를 호출할 수 있습니다.

API Key는 이 키를 생성한 관리자와 동일한 관리자로 수행되기 때문에 잘 관리를 해줘야 하는 필요성이 있습니다.

API Key를 이용하여 REST API를 호출하는 방법은 아래와 같습니다.

•APIKey를 이용하여 태그의 정보 가져오는 예

◦GET  http://centerip/mc2/rest/nodes/{nodeid}/tags?apiKey={apikey}

위와 같이 관리자 상세화면에서 생성한 apikey를 파라미터로 같이 전달해서 API를 호출할 수 있습니다.


[관리자 설정 화면에서 API 키 생성]

마치며

Genian NAC에는 연동을 위해 REST API 외에 다른 API들을 제공하고 있습니다.

몇가지 문제점은 사용하기 어려운 부분이나 기능의 범용성이 떨어지는 부분들이 존재한다고 생각합니다.

그렇다고 REST API가 확실한 대안인가?라고 하기에는 아직 부족한 부분들이 존재합니다.

하지만 HTTP를 이용한 명확한 기능 구성 및 접근성이라는 장점과 SWAGGER를 통한 API 문서화는 기존의 API보다더 쉽고 접근성이 용이하게 되었습니다.

그래서 앞으로도 많은 기능들을 REST API로 추가될 계획이고 이것을 이용하여 좀 더 나은 연동과 가치를 얻게 되었으면 합니다.