API
API는 애플리케이션 소프트웨어를 빌드하고 통합하기 위한 정의 및 프로토콜 세트인 애플리케이션 프로그래밍 인터페이스(Application Programming Interface)를 말한다.
또한, 개발자가 새로운 애플리케이션 구성 요소를 기존 아키텍처에 통합하는 방식을 간소화하므로 비즈니스 팀과 IT 팀의 협업에도 도움이 됩니다.
API 요약
플리케이션 소프트웨어를 구축하고 통합하는 정의 및 프로토콜 세트입니다. 때때로 API는 정보 제공자와 정보 사용자 간의 계약으로 지칭되며 소비자에게 필요한 콘텐츠(호출)와 생산자에게 필요한 콘텐츠(응답)를 구성합니다. 예를 들어 날씨 서비스용 API에서는 사용자는 우편번호를 제공하고, 생산자는 두 부분(첫 번째는 최고 기온, 두 번째는 최저 기온)으로 구성된 응답으로 답하도록 지정할 수 있습니다.
즉, 컴퓨터나 시스템과 상호 작용하여 정보를 검색하거나 기능을 수행하고자 할 때 API는 사용자가 원하는 것을 시스템에 전달할 수 있게 지원하여 시스템이 이 요청을 이해하고 이행하도록 할 수 있습니다.
API를 사용자 또는 클라이언트, 그리고 사용자와 클라이언트가 얻으려 하는 리소스 사이의 조정자로 생각하면 됩니다. API는 조직이 보안 및 제어를 유지관리(누가 무엇에 액세스할 수 있는지 결정)하면서 리소스와 정보를 공유할 수 있는 방법이기도 합니다.
API의 또 다른 이점은 리소스 검색 방법 또는 리소스의 출처에 대한 지식 없이도 사용이 가능하다는 점입니다.
API 작동방법
API를 사용하면 구현 방식을 알지 못하는 제품 또는 서비스와도 통신할 수 있으며 애플리케이션 개발을 간소화하여 시간과 비용을 절약할 수 있습니다. 새로운 툴과 제품을 설계하거나 기존 툴과 제품을 관리할 때 API를 사용하면 유연성을 높이고 설계, 관리, 사용 방법을 간소화 할 수 있다.
클라우드 네이티브 애플리케이션(CNAPP) 개발은 개발 속도를 높이기 위한 식별 가능한 방식이며, API를 통한 마이크로서비스 애플리케이션 아키텍처 연결에 기반합니다.
API는 클라우드 네이티브 애플리케이션 개발을 통해 자체 인프라를 연결하는 간소화된 방식이지만, 고객 및 다른 외부 사용자와의 데이터 공유를 허용하기도 합니다. 퍼블릭 API는 파트너와의 연결 방식을 간소화하고 확대할 수 있을 뿐만 아니라 보유한 데이터를 활용해 수익을 창출할 수 있기 때문에 고유의 비즈니스 가치를 지닙니다.
도서 유통 회사를 예로 들어보면 도서 유통업체에서 고객에게 클라우드 애플리케이션을 제공하여 서점 직원이 유통업체의 물류 재고를 확인하도록 할 수도 있지만 애플리케이션을 개발하는 데 많은 비용과 시간이 들고 플랫폼의 제약을 받을 수 있으며 지속적인 유지관리가 필요합니다.
그 대안이 바로 재고 확인용 API를 제공하는 것입니다.
이 접근 방식에는 다음과 같은 여러 가지 이점이 있습니다.
고객이 API를 통해 데이터에 액세스할 수 있으므로 한곳에서 재고 정보를 통합할 수 있습니다.
API 작동에 변화가 없는 한, 도서 유통업체는 고객에게 영향을 미치지 않고 내부 시스템을 변경할 수 있습니다.
도서 유통업체의 개발자, 도서 판매자 또는 제3자가 공개적으로 제공되는 API를 이용하여 고객이 원하는 도서를 찾도록 도와주는 애플리케이션을 개발할 수 있으며 이는 매출을 늘리거나 다른 쪽으로 더 활용 가능합니다.
간단히 말해서, API는 리소스에 대한 액세스 범위를 넓히는 동시에 보안과 제어를 유지할 수 있도록 합니다. 액세스 권한을 어떻게, 누구에게 제공할지 여부만 결정하면 됩니다. API 보안이란 결국 효과적인 API 관리를 의미하며, 여기에는 API 게이트웨이 사용이 포함됩니다. 레거시 시스템과 사물 인터넷(IoT)을 비롯하여 어떤 환경이든 연결하는 분산형 통합 플랫폼을 통해 API에 연결하고 API에 의해 노출된 데이터 또는 기능을 사용하는 애플리케이션을 만들 수 있습니다.
API 릴리즈 정책
1.프라이빗
-API를 내부에서만 사용할 수 있도록 하며 기업이 API를 최대한으로 제어 할 수 있다.
2.파트너
API를 특정 비즈니스 파트너와 공유하며 품질 저하 없이 추가 수익원을 창출 할 수 있다.
3.퍼블릭
-API가 모두에게 제공되며 제 3자가 API와 상호 작용하는 애플리케이션을 개발하여 더욱 가치있는 개발이 가능하다.
API를 통한 변화
파트너 또는 일반 사용자에게 API를 공개하면 다음과 같은 이점이 생긴다.
1.새로운 수익 채널을 확보하거나 기존 수익 채널을 확장합니다.
2.브랜드 인지도를 확대합니다.
3.외부 개발을 활용하고 협업을 수행하여 오픈 혁신을 촉진하거나 효율성을 높입니다.
도서 유통업체의 예로 돌아가 보자
이 회사의 한 파트너가 서점에서 원하는 도서를 쉽게 찾을 수 있는 애플리케이션을 개발한다고 가정해 보겠습니다. 이렇게 고객 환경을 개선하면 더 많은 손님이 서점을 찾을 것이고 기존의 수익 채널이 확대되는 효과를 얻게 됩니다.
제 3자가 퍼블릭 API를 사용하여 매장이 아니라 유통업체로부터 직접 도서를 구입하는 애플리케이션을 개발할 수도 있으며 이는 도서 유통업체에게 새로운 수익 채널을 열어 줍니다.
특정 파트너 또는 전 세계 사람들과 API를 공유하면 긍정적인 효과를 가져올 수 있으며 각각의 파트너십을 통해 브랜드 인지도 측면에서 회사 자체의 마케팅 활동을 넘어서는 성과를 거둘 수 있습니다. 퍼블릭 API처럼 기술을 모든 사람에게 공개하면 개발자가 API를 사용하여 애플리케이션의 에코시스템을 구축할 수 있습니다. 더 많은 사람들이 기술을 사용할수록 비즈니스를 함께할 사람도 늘어나게 됩니다.
기술을 대중에게 공개함으로써 예기치 않은 결과가 발생할 수도 있으며 이 결과가 전체 산업을 와해시키기도 합니다. 앞서 예를 든 도서 유통업체의 경우 도서 대여 서비스를 제공하는 새로운 기업이 나타나 비즈니스 방식을 근본적으로 바꿀 수 있으며, 파트너 그리고 퍼블릭 API를 통해서는 내부 개발자 팀보다 규모가 큰 커뮤니티에서 발휘되는 창의력을 활용할 수 있습니다. 새로운 아이디어는 어디서든 나올 수 있으며 기업은 시장의 변화를 인지하고 적절히 대응할 준비를 갖춰야 합니다. 바로 여기서 API가 큰 도움이 될 수 있습니다.
원격 API
원격 API는 커뮤니케이션 네트워크를 통해 상호 작용하도록 설계되었습니다. 여기서 원격이란 API에 의해 조작되는 리소스가 요청을 보내는 컴퓨터의 외부에 있음을 의미합니다. 가장 광범위하게 사용되는 커뮤니케이션 네트워크가 인터넷이기 때문에 대부분의 API는 웹 표준을 기반으로 설계되며, 모든 원격 API가 웹 API인 것은 아니지만 웹 API가 원격이라고 가정할 수는 있습니다.
웹 API는 일반적으로 요청 메시지에 HTTP를 사용하여 응답 메시지 구조의 정의를 제공합니다.
이러한 응답 메시지는 일반적으로 XML 또는 JSON 파일의 형태입니다.
다른 애플리케이션이 쉽게 조작할 수 있는 방식으로 데이터를 표시하므로 XML과 JSON 둘 다 자주 사용됩니다.
SOA와 MSA의 차이
원격 API를 가장 많이 사용하는 두 가지 아키텍처 접근 방식은 SOA(서비스 지향 아키텍처)와 마이크로서비스 아키텍처입니다. 이 두 가지 접근 방식 중에서 더 일찍 개발된 SOA의 초기 모습은 모놀리식(Monolithic) 애플리케이션을 개선한 것이었습니다. 하나의 모놀리식 애플리케이션이 모든 작업을 수행하지만 일부 기능은 ESB(엔터프라이즈 서비스 버스)와 같은 통합 패턴을 통해 느슨하게 연결된 다른 애플리케이션에서 제공될 수 있습니다.
SOA는 모든 면에서 모놀리식 아키텍처보다 단순하지만 구성 요소의 상호 작용에 대해 명확한 이해가 이루어지지 않을 경우 다양한 변경이 환경 전체 복잡성을 가중할 위험이 있습니다. 이처럼 복잡성이 더해지면서 SOA가 해결해야 할 일부 문제가 다시 발생합니다.
마이크로서비스 아키텍처는 느슨하게 연결된 전문 서비스를 사용한다는 점에서 SOA 패턴과 유사하나, 여기서 더 나아가 전통적인 아키텍처를 더욱 세분화합니다. 마이크로서비스 아키텍처 내의 서비스는 RESTful API와 같은 일반적인 메시징 프레임워크를 사용합니다. RESTful API를 사용하면 어려운 데이터 변환 트랜잭션이나 추가 통합 계층 없이 상호 커뮤니케이션을 구현할 수 있으며, 새로운 기능과 업데이트를 더 빠르게 제공할 수 있습니다. 각 서비스는 개별적으로 제공되며 아키텍처의 다른 서비스에 영향을 미치지 않고 하나의 서비스를 교체하거나 강화하거나 삭제할 수 있습니다. 이 경량화된 아키텍처는 분산된 리소스나 클라우드 리소스를 최적화하고 개별 서비스의 동적 확장성을 지원합니다.
출처:https://www.redhat.com/ko/topics/api/what-are-application-programming-interfaces
