API란 어플리케이션 프로그래밍 인터페이스(Application Programming Interface)의 약자로, 소프트웨어 응용 프로그램에서 다른 소프트웨어 구성 요소 또는 서비스와 상호 작용을 하기 위한 인터페이스를 제공하는 프로그래밍 기술을 뜻한다.
무슨 말인지 한번에 와닿지 않는데, 실제로는 무수히 많은 API를 접하게 될 것이고 경험에 익숙해져만 갈 것이다. 하지만 정확한 뜻을 이해를 하고 활용해야 진정 안다고 할 수 있을 것이다.
Application
> 특정한 업무를 수행하기 위해 개발된 응용 소프트웨어
Progamming
> 컴퓨터에 부여하는 명령을 만드는 작업, 수식이나 작업을 컴퓨터에 알맞도록 정리해서 순서를 정하고 컴퓨터 특유의 명령코드로 고쳐 쓰는 작업
Interface
> 사물과 사물 사이 또는 사물과 인간 사이의 경계에서, 상호간의 소통을 위해 만들어진 물리적인 매개체나 통신 규칙
정말 간단하게 예시를 들어 설명하자면,
손님이 레스토랑에서 웨이터에게 주문을 하면 웨이터는 주문 내역을 주방의 주방장에게 갖다줄 것이고, 주방장은 요리를 해서 웨이터에게 주면 웨이터는 손님에게 요리를 전달할 것이다.
여기서 손님은 내가 만든 프로그램이 되는 것이고, 웨이터는 API, 주방장이 API 제공자가 되는 것이다.
간단한 예시로 API에 대해 자세히는 모르지만 간접적으로 알 수 있게 되었는데, 사전적인 정의를 알아보자
API는 여러 프로그램들과 데이터베이스, 기능들의 상호 통신 방법을 규정하고 도와주는 매개체이다. API는 데이터베이스가 아니지만, 액세스 권한이 있는 앱의 권한 규정과 서비스 요청에 따라 데이터나 서비스 기능을 제공하는 메신저 역할을 한다.
API의 필요성은 웹의 진화와 밀접한 연관이 있으니 잠깐 살펴보면, 모놀리틱 아키텍처(Monolithic Architectrue)가 주도적이었던 Web 1.0 시대에는 서버와 클라이언트가 분리되지 않고 모두 서버에서 동시에 처리하기 때문에 API의 필요성이 그다지 절실하지 못했다.
그러나 2000년 즈음부터 시작된 Web 2.0의 개방, 참여, 공유의 정신을 바탕으로 정보가 쌍방향으로 소통하고 사용자가 생성한 데이터를 위주로 웹 앱의 붐, 그리고 2010년대에 들어서 클라우드 기반의 인프라와 MSA(Microservices Architecture)의 사용이 확산되면서 API의 확산이 가속화 되었고, 이제 API에서 가장 흔한 구조인 REST 또는 RESTful API가 점차 새로운 웹 생태계의 기반으로 주목된 것이다.
Private API는 내부 API로, 기업이나 연구 단체 등에서 자체 제품과 운영 개선을 위해 단체 내부에서만 사용, 따라서 외부에 노출되지 않는다.
Public API는 개방형 API로 모두에게 공개되어있다. Public API 중에서도 접속하는 대상에 대한 제약이 없는 경우를 OpenAPI라고 부른다.
몇가지 OpenAPI 사이트
- 구글 : https://cloud.google.com/apis?hl=ko
- 공공데이터포털- https://www.data.go.kr/
- 문화데이터 광장 – https://www.culture.go.kr/data/main/main.do
- 카카오 : https://developers.kakao.com/tool
Partner API는 특정 비즈니스 파트너간의 데이터 공유를 위한 API, 서로에게 공유를 동의하는 특정인들만 사용할 수 있는 경우이다.
각각 유형과 기능, 보완 지원방식 등의 차이점이 존재한다. 이 종류에서 현 시점을 기준으로 REST/RESTful API와 GraphQL을 더욱 살펴보기를 권장되고, 현재 사실상 표준화가 되었다 해도 과언이 아닐 정도로 가장 많이 쓰이고 있는 REST API를 중점으로 쓴다.
(REST는 'REpresentational State Transfer' 을 뜻함.)
데이터 접속의 표준화와 편의성
위의 접근 방식에 따른 public API와 Partner API 등의 종류들에서 알아봤듯이 API는 모든 접속을 표준화하기 때문에 디바이스, 운영체제 등과 상관없이 조건만 맞다면, 범용 플러그처럼 누구나 동일한 액세스를 약속하게된다. 조직에서 애플리케이션을 개발할 경우 기능적 API를 사용하면, 필요한 기본 기능들을 매번 자가 개발, 업데이트 할 필요없이 손쉽게 이용할 수 있다는 장점이 있다.
자동화와 확장성
API를 통한 CRUD 처리에 따라 관련 데이터와 콘텐츠가 자동으로 생성되고 사용자의 환경에 맞춰서 정보가 전달되어 개발 워크플로우가 간소화되고 애플리케이션 확장이 다소 용이하다. 예를 들면 API를 활용한 웹 사이트 분석, 프로젝트 및 팀관리 도구, 온라인 결제 시스템, 기타 여러 운영 솔루션에 필요한 애플리케이션을 다소 쉽게 작성할 수 있다.
적용력
API는 변화 예측에도 큰 도움이 되기 때문에 API를 통해 데이터를 수집하고 전달하는 데 있어 유연한 서비스 환경을 구축하고 소프트 웨어를 통합하고자 할 때, 그리고 개발자들 간의 협업이 필요할 때 더욱 용이해진다.
보안성과 HTTP 방식의 제한
API의 단일 진입점인 API 게이트웨이는 해커의 타겟 대상이 될 수 있다. API의 장점이 보안성에 관해서는 크나큰 단점이 될 수 있다는 뜻이다. 이 때문에 다른 일반적인 인터넷 기반 리소스와 마찬가지로 메세지 가로채기 공격(main-in-the-middle), CSRF(Cross-Site Request Forgery)공격, 크로스 사이트 스크립팅(Cross Site Scripting, XSS), SQL 삽입 공격(SQL injection), DDoS(Denial-of-service attack) 등에 취약한 것이 사실이다. 또한 이러한 HTTP method는 메소드 형태가 다소 제한적이라는 문제점이 있다.
표준의 부재와 개발 비용
REST API의 설계에 있어 가장 큰 단점이라고 할 수 있는 부분은 공식화된 표준이 존재하지 않는다는 점이다. 그러므로 관리가 어렵고 실제로 API 기능을 구현하고 제공하려면 개발 시간, 지속적인 유지 관리 요구 사항 및 지원 제공 측면에서 비용이 많이 들 수 있다. 또한 기존 API의 기능을 확장하려고 할 때 광범위한 프로그래밍 지식이 필요하다.
참고 문서 : https://www.redhat.com/ko/topics/api/what-is-a-rest-api,
https://www.redhat.com/architect/apis-soap-rest-graphql-grpc,
https://aws.amazon.com/ko/what-is/restful-api/