API란?

• 정의 및 프로토콜 집합을 사용해 각 소프트웨어 구성 요소가 통신할 수 있게 하는 메커니즘이다

API가 하는 역할

API는 "Application Programming Interface"의 약자로써

• Application : 고유 기능을 가진 모든 소프트웨어
• Interface : 두 애플리케이션 간의 서비스 계약

=> 요청과 응답을 사용해 두 애플리케이션이 서로 통신하는 방법을 정의

API 역사

API는 DB는 아니지만, 엑세스 권한이 있는 앱의 권한 규정과 "서비스 요청"에 따라 데이터나 서비스 기능을 제공하는 메신저 역할을 한다.

여기서 의문! 그냥 DB를 연결하지 굳이 왜 이런 매개체가 필요한가?

Web의 진화와 API

API의 필요성은 Web의 진화와 밀접한 연관이 있다.
모놀리틱 아키텍처(Monolithic Architecture)가 주도적이었던 Web 1.0 시대에서는 서버와 클라이언트가 분리되지 않고 모두 서버에서 동시에 처리했기 때문에 API의 필요성이 절실하지 않았다.

그러나 Web2.0의 "개방, 참여, 공유"의 정신을 바탕으로 정보가 쌍방향으로 소통하고 사용자가 생성한 데이터를 위주로 웹 앱의 붐, 2010년대 들어서 클라우드기반 인프라와 MSA(Microservices Architecture)의 사용 증가로 API 확산이 가속화되었고, 이제 API에서 가장 흔한 구조인 REST 또는 RESTful API가 점차 새로운 웹 생태계의 기반으로 주목되었다.

아키텍처 스타일에 따른 API 종류

SOAP API

• 단순 객체 접근 프로토콜을 사용

• 클라이언트와 서버는 XML을 사용하여 메시지 교환

• 과거에 더 많이 사용되었으며 유연성이 떨어짐

RPC API

• 원격 프로시저 호출이라고 함

• 클라이언트가 서버에서 함수or프로시저 완료 => 서버가 출력을 클라이언트로 다시 전송

Websocket API

• JSON 객체를 사용하여 데이터를 전달하는 또 다른 최신 웹 API

• 클라이언트 앱과 서버 간의 양방향 통신을 지원

• 서버는 연결된 클라이언트에 콜백 메시지를 전송할 수 있음

REST API

• 오늘날 웹에서 볼 수 있는 가장 많이 사용되고 유연한 API

클라이언트가 서버에 요청을 데이터로 전송 -> 서버가 클라이언트의 입력을 사용해 내부 함수를 시작 -> 출력 데이터를 다시 클라이언트에 반환

접근 방식에 따른 API 종류

Private API

• 기업, 연구 단체 등에서 자체 제품 운영 개선을 위해 내부에서만 사용할 수 있도록 하는 API

• 제 3자에게 노출X

• 기업이 API를 최대한으로 제어 가능

• 비즈니스 내에서 시스템과 데이터를 연결하는 데만 사용

Public API

• 개방형 API로 모두에게 공개

• Public API 중에서도 접속하는 대상에 대한 제약이 없는 경우를 OpenAPI라고 함

• API가 모두에게 제공되며, 제 3자가 상호 작용하는 앱을 개발하여 혁신을 끌어낼 수 있음

• 이러한 유형의 API와 관련된 권한 부여와 비용이 있을 수도 있고 없을 수도 있음

Partner API

• 특정 비즈니스 파트너 간의 데이터 공유 API

• 동의하는 특정인들만 사용 가능

• 품질 저하 없이 추가 수익원을 창출 가능

• B2B 파트너십을 지원하기 위해 권한이 부여된 외부 개발자만 액세스 가능

API의 장점

데이터 접속의 표준화

• API는 모든 접속을 표준화
  => 디바이스/운영체제 등 상관없이 조건만 맞다면 누구나 동일한 액세스를 약속

편의성

• 조직에서 애플리케이션 개발 시 기능적 API를 사용 가능
  => 필요한 기본 기능들(인증, 통신, 지불 처리 및 위치 확인 등)을 매번 자가 개발/업데이트할 필요 없이 손쉽게 이용 가능

• 결과적으로 매번 재발명할 필요가 없음

자동화와 확장성

• API를 통한 CRUD 처리에 따라 관련 데이터와 콘텐츠가 자동 생성

• 사용자의 환경에 맞춰서 정보가 전달 되어 개발 워크플로우 간소화

• 애플리케이션 확장이 다소 용이

적용력

• 변화 예측에도 큰 도움 가능

• API를 통해 데이터 수집 및 전달에 유연한 서비스 환경 구축 가능

• 소프트 웨어 통합 시 용이

• 개발자들 간의 협업 필요 시 더욱 용이

API의 단점

보안성과 HTTP 방식의 제한

• API의 단일 진입점인 API 게이트웨이가 해커의 타겟 대상이 될 수 있음

  즉 API의 장점(평범한 HTTP 메서드를 사용해 액세스 가능)이 보안 측면에서 크나큰 단점이 된다. 이 때문에 다른 일반적 인터넷 기반 리소스와 마찬가지로 메시지 가로채기 공격(man-in-the-middle), CSRF(Cross-Site Request Forgery) 공격, 크로스 사이트 스크립팅(Cross Site Scripting, XSS), SQL 삽입 공격(SQL injection), DDoS(Denial-of-service attack) 공격 (서비스 거부 공격) 등에 취약다. 또한 이러한 HTTP method는 메서드 형태가 다소 제한적이라는 문제점이 있다.

표준의 부재와 개발 비용

• REST API의 설계에 있어 가장 큰 단점 = 공식화된 표준이 존재X

• 관리가 어려움

• 실제 API 기능 구현 및 제공을 위한 개발 시간, 지속적인 유지 관리 요구 사항 및 지원 제공 측 비용이 많이 들 수 있음

• 기존 API의 기능을 확장 시 광범위한 프로그래밍 지식이 필요