API와 전문통신의 차이

전문, 전문통신

전문의 개념

전문 통신 방식이란 통신에 참여하는 애플리케이션들이 주고 받을 데이터의 포맷을 서로 약속(프로토콜)한 후 약속된 데이터 패킷을 전송하고 수신하는 것을 말한다

초창기 클라이언트/서버 환경에서 애플리케이션 사이의 통신은 네트워크 패킷(packet) 기반의 전문 방식이 주로 사용됐다.

그림의 예와 같이 통신을 위한 패킷을 정의하고 이 데이터 패킷을 애플리케이션이 주고 받게 된다. 클라이언트는 약속된 데이터 패킷의 포맷에 맞춰 패킷을 생성, 서버로 전송한다. 서버는 패킷을 읽어 들이고 패킷에 기록된 데이터를 해석해 필요한 서버 측 작업을 수행하고 그 결과를 데이터 패킷에 기록해 클라이언트로 반환하는 것이다

전문의 단점

이러한 기존의 전문 방식의 클라이언트/서버 통신은 개발 생산성이 너무 낮았고 애플리케이션들이 복잡해짐에 따라 수 백 수 천 개의 데이터 패킷 정의를 요구했다. 또한 과거 메인 프레임에서 가능했었던 트랜잭션 처리와 같은 고급 데이터 처리 기법 역시 새로운 클라이언트/서버 환경에 요구됐다.
따라서 클라이언트와 서버 사이에 데이터 패킷 생성 및 전달과 더불어 네트워크 상에 분산돼 있는 서버들을 찾아주는 네이밍(naming) 서비스, 트랜잭션 서비스 등을 제공하는 미들웨어(middleware)들이 등장하기 시작했다.
이러한 미들웨어를 통해 개발자는 클라이언트와 서버 측에서 애플리케이션 비즈니스 로직에 관련된 핵심코드만을 작성하는 편리성을 제공하고 이를 통해 생산성을 높일 수 있도록 했다.
미들웨어를 사용하면 더 이상 개발자가 Socket API를 직접 액세스할 필요가 없어지며 복잡한 TCP/IP 오류 처리 등을 고려하지 않아도 되었다.

[출처] http://www.libqa.com/wiki/116

API

API의 정의

API는 애플리케이션 소프트웨어를 구축하고 통합하기 위한 정의 및 프로토콜 세트로, 애플리케이션 프로그래밍 인터페이스(Application Programming Interface)를 나타냅니다.

API의 장점

API를 사용하면 구현 방식을 알지 못해도 제품 또는 서비스가 서로 커뮤니케이션할 수 있으며 애플리케이션 개발을 간소화하여 시간과 비용을 절약할 수 있습니다. 새로운 툴과 제품을 설계하거나 기존 툴과 제품을 관리하는 경우 API는 유연성을 제공하고 설계, 관리, 사용 방법을 간소화하며 혁신의 기회를 제공합니다.
API는 클라우드 네이티브 애플리케이션 개발을 통해 자체 인프라를 연결하는 간소화된 방식이지만, 고객 및 다른 외부 사용자와의 데이터 공유를 허용하기도 합니다. 퍼블릭 API는 파트너와의 연결 방식을 간소화하고 확대할 수 있을 뿐만 아니라 보유한 데이터를 활용해 수익을 창출할 수 있기 때문에 고유의 비즈니스 가치를 지닙니다(예: Google Maps API).

API 활용 예시

도서를 유통하는 회사를 한 예로 들어보겠습니다. 이 도서 유통업체에서 고객에게 애플리케이션을 제공하여 서점 직원이 유통업체의 도서 재고를 확인하도록 할 수도 있지만, 애플리케이션을 개발하는 데 많은 비용과 시간이 들고 플랫폼의 제약을 받을 수 있으며 지속적인 유지관리가 필요할 것입니다.

그 대안이 바로 재고 확인용 API를 제공하는 것입니다. 이 접근 방식에는 다음과 같은 여러 가지 이점이 있습니다.

고객이 API를 통해 데이터에 액세스할 수 있으므로 한곳에서 재고 정보를 통합할 수 있습니다.
API 작동에 변화가 없는 한, 도서 유통업체는 고객에게 영향을 미치지 않고 내부 시스템을 변경할 수 있습니다.
도서 유통업체의 개발자, 도서 판매자 또는 제3자가 공개적으로 제공되는 API를 이용하여 고객이 원하는 도서를 찾도록 도와주는 애플리케이션을 개발할 수 있으며 이는 매출을 늘리거나 기타 비즈니스 기회를 창출할 수 있습니다.
간단히 말해서, API는 리소스에 대한 액세스 권한을 제공하고 보안과 제어를 유지할 수 있게 해주며 액세스 권한을 어떻게, 누구에게 제공할지 여부만 결정하면 됩니다. API 보안이란 결국 API를 잘 관리하는 것을 의미합니다. API에 연결하고 API에 노출된 데이터 또는 기능을 사용하는 애플리케이션을 생성하는 것은 레거시 시스템과 IoT(사물 인터넷)를 비롯하여 어떤 환경이든 연결하는 분산형 통합 플랫폼을 통해 수행할 수 있습니다.

API 정책 유형

API 릴리스 정책은 다음과 같은 세 가지 접근 방식을 취합니다.

• Private : 내부에서만 사용,
• Partner : + 특정 파트너와 공유
• Public : API가 모두에게 제공 & 제3자가 API와 상호작용하는 App 개발 가능

원격 API와 웹 API

원격 API는 커뮤니케이션 네트워크를 통해 상호 작용하도록 설계되었습니다. 여기서 '원격'이란 API에 의해 조작되는 리소스가 요청을 보내는 컴퓨터의 외부에 있음을 의미합니다. 가장 광범위하게 사용되는 커뮤니케이션 네트워크가 인터넷이기 때문에 대부분의 API는 웹 표준을 기반으로 설계되며, 모든 원격 API가 웹 API인 것은 아니지만 웹 API가 원격이라고 가정할 수는 있습니다.

웹 API는 일반적으로 요청 메시지에 HTTP를 사용하여 응답 메시지 구조의 정의를 제공합니다. 이러한 응답 메시지는 일반적으로 XML 또는 JSON 파일의 형태입니다. 다른 애플리케이션이 쉽게 조작할 수 있는 방식으로 데이터를 표시하므로 XML과 JSON 둘 다 자주 사용됩니다.

API 구현 방법

API가 유비쿼터스형 웹 API로 발전하면서 설계 편의성과 구현 유용성을 높이기 위한 노력이 다각도로 이루어지고 있습니다.

SOAP 감소, REST API 증가

웹 API가 확산됨에 따라, 정보 교환을 표준화하기 위해 SOAP(Simple Object Access Protocol)라는 프로토콜 사양이 개발되었습니다. SOAP로 설계된 API는 XML 메시지 형식을 사용하며 HTTP 또는 SMTP를 통해 요청을 수신합니다. SOAP를 사용하면 더 간편한 방법으로 애플리케이션을 다양한 환경에서 실행하거나 다양한 언어로 작성하여 정보를 공유할 수 있습니다.

또 다른 사양은 REST(Representational State Transfer)로, REST 아키텍처의 제약 조건을 준수하는 웹 API를 RESTful API라고 합니다. SOAP는 프로토콜이지만 REST는 아키텍처 스타일이라는 근본적인 차이가 있으며 따라서 RESTful 웹 API에는 공식적인 표준이 없습니다. Roy Fielding의 논문인 '네트워크 기반 소프트웨어 아키텍처의 구조적 스타일과 설계(Architectural Styles and the Design of Network-based Software Architectures)'에 정의된 것처럼 RESTful 시스템의 다음 6가지 주요 제약 조건을 준수했을 때 RESTful API라고 간주할 수 있습니다.

RESTful API가 SOAP보다 더 많이 사용되고 있습니다. 최근 몇 년간 OpenAPI 사양은 REST API를 정의하는 공통 표준으로 부상했습니다. OpenAPI는 언어 독립적인 방식으로 개발자들이 REST API 인터페이스를 구축하여 사용자가 별다른 추측 없이도 이를 사용할 수 있도록 합니다.

SOA와 마이크로서비스 아키텍처 비교

원격 API를 가장 많이 사용하는 두 가지 아키텍처 접근 방식은 SOA(Service-Oriented Architecture)와 마이크로서비스 아키텍처입니다. 이 두 가지 접근 방식 중에서 더 일찍 개발된 SOA의 초기 모습은 모놀리식(Monolithic) 애플리케이션을 개선한 것이었습니다. 하나의 모놀리식 애플리케이션이 모든 작업을 수행하지만 일부 기능은 ESB(엔터프라이즈 서비스 버스)와 같은 통합 패턴을 통해 느슨하게 연결된 다른 애플리케이션에서 제공될 수 있습니다.

SOA는 모든 면에서 모놀리식 아키텍처보다 단순하지만 구성 요소의 상호 작용에 대해 명확한 이해가 이루어지지 않을 경우 다양한 변경이 환경 전체 복잡성을 가중할 위험이 있습니다. 이처럼 복잡성이 더해지면서 SOA가 해결해야 할 일부 문제가 다시 발생합니다.

마이크로서비스 아키텍처는 느슨하게 연결된 전문 서비스를 사용한다는 점에서 SOA 패턴과 유사하나, 여기서 더 나아가 전통적인 아키텍처를 더욱 세분화합니다. 마이크로서비스 아키텍처 내의 서비스는 RESTful API와 같은 일반적인 메시징 프레임워크를 사용합니다. RESTful API를 사용하면 어려운 데이터 변환 트랜잭션이나 추가 통합 계층 없이 상호 커뮤니케이션을 구현할 수 있으며, 새로운 기능과 업데이트를 더 빠르게 제공할 수 있습니다. 각 서비스는 개별적으로 제공되며 아키텍처의 다른 서비스에 영향을 미치지 않고 하나의 서비스를 교체하거나 강화하거나 삭제할 수 있습니다. 이 경량의 아키텍처는 배포된 리소스나 클라우드 리소스를 최적화하고 개별 서비스의 동적 확장성을 지원합니다.

 

 

[출처] https://www.redhat.com/ko/topics/api/what-are-application-programming-interfaces