API의 정의 : API란 무엇인가?

API가 무엇인지 다들 알고 있지만,
똑 부러지게 “이거다.”라고 이야기하는 사람도 없습니다.

이유는 API라는 용어가 포괄적으로 사용되어지고 있기 때문입니다.
Wikipedia를 번역하여, 내용의 이해를 돕고자 합니다.

※ 원문 : http://en.wikipedia.org/wiki/Application_programming_interface

01. API의 정의

API는 어플리케이션을 만들기 위한 하위 함수, 프로토콜, 도구들의 집합을 말한다.
즉 명확하게 정의된 다양한 컴포넌트 간의 통신 방법이다.

좋은 API 는 프로그래머들이 빌딩블럭 쌓듯이 쉽게 소프트웨어를 개발할 수 있게 해준다.
그래서 OS, DB, HW, SW library, Web기반시스템 등.
다양한 곳에서 API를 만든다.

루틴, 데이터구조, object class, 변수, 리모트호출 등 여러가지 스펙으로도 만들어진다.
MS Window API, Java API 등등은 다양한 API의 모습이다.

다만, API의 지적재산권은 아직 토론의 여지가 많다.

02. 목적

GUI가 일반인들이 프로그램을 사용하기 쉽게 만들어 준다면,
API는 프로그래머가 특정 기술을 쉽게 사용할 수 있도록 해준다.

개발자들에게 필요한 기능들을 추상화하고, Object, Class 등을 제공한다.
그 기능을 이해하고 사용하기 위한 “인지부하”를 줄여준다.

예를 들어 메일 서비스를 제공한다고 하자.

일반인 대상이라면 “메일작성 버튼”을 만드는 게 중요하다.
그래야 쉽게 사용할 수 있다.

개발자 대상이라면 “File API”에 OS나 파일시스템에 상관없이
파일을 복사, 전송하는 기능을 만들어준다.

개발자들은 API를 써서 마음대로 파일을 이리저리 이동시킬 것이다.

03. 사용방법

가. Library와 Framework

API는 Software Library 와 관계가 있다.
Library가 실제 “구현된 기능 Implementation”이라면,
API 는 그걸 사용하기 위해 예상되는 행동들이다.
(Copy API 는 복사행위를 기대함. Copy Library는 실제 복사를 함)

API 는 Implementation와 한덩어리로 구현될 수 있다.
그래서 API 모습은 같아도 서로 다른 Library를 가지고 있을 수 있다.

API 를 Implementation과 분리하는 것은,
다른 언어로 개발된 기능을 내 소스코드 내에서 쓸 수 있다는 것을 의미한다.

예를 들면 Scala 와 Java 는 바이트코드가 호환되기 때문에,
Scala 개발자들은 Java API를 쉽게 이용할 수 있다.

API 사용법이 구현된 언어에 따라 다를 수 있다.
예를 들어 절차형 언어인 Lua 로 개발된 경우,
코드 실행, 데이터 처리, 에러 핸들링 기능으로 구성되어 있다.

하지만, Java API 는 여러개의 class와 method로 구성되어 있다.
따라서 호출방법과 사용방법이 달라진다.

언어 연결도 API의 영역이다.
SWIG 을 F2PY로, Fortran 을 Python으로 연결하는 역할을 API로 할 수 있다.

API 는 software framework 과도 관계가 있다.
framework 이란 다수의 API 를 실행하는 여러 개의 library 로 구성되어 있다.

그런데 framework 은 일반적인 API 사용법과 달리,
새로운 class 를 추가함으로써 그 기능을 사용할 수 있다.

그리고 전체적인 통제가 호출자가 아닌 프레임에 있다는 게 다르다.

나. 운영체제

API 는 어플리케이션과 운영체제를 연결해주기도 한다.
예를 들어 POSIX 는 어플리케이션이 운영체제들과 통신하기 위한
공통 API 규격들을 제공하고 있다.

이를 구현한 대표적인 사례로 Linux 와 버클리 재단이 있다.

MS 도 호환 API 의 대표 주자이다.
비록 윈도우에 한정되어서지만, 그들은 API 를 이용해서
거의 완벽하게 하위 호환성을 지원하고 있기 때문이다.

그런데, API 는 소스코드를 제공한다는 측면에서 ABI (binary) 와는 차이가 있다.
예를 들어 POSIX 는 API 이지만, Linux 는 ABI 라고 할 수 있다.

다. Remote API

Rmote API 는 개발자들이 프로토콜을 이용하여
원격지에 있는 자원을 활용할 수 있게 한다.
그래서 서로 다른 기술들이 함께 동작할 수 있도록 도와준다.

예를 들면 Java DB connection API 가 그렇다.
이 API 는 개발자들이 하나의 function으로
다양한 Database 들을 사용할 수 있도록 도와준다.

그래서 remote API 는 객체지향 프로그래밍에서 객체 추상화를 유지하기에 매우 유용하다.
원격지의 변경에도 내부 코드들이 변경될 필요가 없어진다.

라. Web API

Web API 는 전체 시스템과 그 리소스를 사용하는
어플리케이션 간의 연결시키는 인터페이스이다.

API 설계는 서로 다른 고객들을 가진 두 개 이상의 서비스를 연결해야 할 때 매우 필요하다.
웹 분야에 서 API 는 단순히 http 프로토콜, XML, JSON 규격처럼 정의되어 있다.

Web API 가 웹 서비스와 거의 동급으로 불리는 반면,
최근의 트렌드는 SOA 기반의 SOAP 프로토콜이, ROA 기반의 REST 프로토콜로 옮겨가고 있다.

이런 움직임의 일부는 시맨틱 웹 운동이나 온톨로지 기술과도 관계가 있다.
Web API 는 여러 개의 조합을 통해 매쉬업 어플리케이션이 가능하게 만들어 주기 때문이다.

그리고, 소셜 공간에서는 웹 커뮤니티들이 쉽게 컨텐츠를 공유할 수 있게 만들어 준다.
그래서 점점 더 웹이 다양하고 복잡해질 수 있게 한다.

04. 설계

API 의 설계는 ‘사용성’에 큰 영향을 끼친다.
특히 ‘정보 은닉’ 원칙은 모듈화 도구로서의 API 역할을 기술하고 있기도 하다.

모듈화란 모듈 내의 복잡성을 사용자가 이해할 필요가 없다는 뜻이다.
그래서 API 를 설계할 때는 사용자가 해당 모듈에 기대하는 기능만 포함하는 것이 좋다.

전체적인 프로그래밍 인터페이스 설계는 소프트웨어 아키텍쳐의 가장 중요한 부분과
복합적인 부분을 대표한다고도 볼 수 있다.

05. API 정책

API 는 기술기업이 다른 기업들을 통합하는 가장 일반적인 방법 중의 하나이다.
API 를 제공하고 사용하는 기업들은 비즈니스 생태계의 구성원이 된다는 뜻이다.

API 를 배포하는 정책들은 다음과 같다.

Private : 회사 내부에서만 사용되는 경우
Partner : 지정된 회사만 API 를 사용할 수 있다.
예를 들면 Uber와 Lyft 는 3rd Party 개발자들이 바로 주문을 내릴 수 있도록
API 를 개방했는데, 이것이 새로운 수익 흐름을 만들어 주었다.
Public : 모든 사람들이 사용할 수 있도록 오픈된다.

06. Public API의 의미

Public API 가 될 때 가장 중요한 것은 ‘인터페이스 안정성’이다.
파라미터 하나를 추가하는 것 조차도 기존 고객들의 시스템을 파괴해 버릴 수 있다.

그래서 Public API 로 배포되는 경우 아직 개발 중이라면
unstable(불안정) 할 수 있다고 반드시 표시를 해 주어야 한다. (또는 베타라고)

간혹 Public API 중에는 일부 기능이 deprecated 되었다고 나온다.
이것은 이 기능이 곧 제거될 예정이고 더 이상 하위호환성을 지원하지 않는다는 걸 말해준다.
그래서 개발자들이 그 API 를 제거하거나 다른 기능으로 갈아타라는 뜻이다.

07. 저작권 논란

2010년 오라클이 구글을 대상으로 ‘안드로이드가 Java API 를 도용했다고’고 고소를 했다.
(즉 Java API 명칭은 그대로 쓰고 소스코드를 안드로이드에 맞게 고친 것.)
구글은 OpenJDK 프로젝트에 대해 비슷한 권리를 얻기는 했지만,
Java API 에 대한 권리를 얻은 것은 전혀 없었다.

판결문 : 오라클의 항소를 받아들이면 사람들이 시스템 명령어를 실행하기 위해 딱 그 버전만을 사용해야 한다는 것이 된다. 즉 같은 명령어를 실행하기 위해 다른 버전을 사용할 수 없다는 뜻이다.

그런데 2014년 항소심에서 윌리엄의 판결이 뒤집혔다.
2016년 또다시 그 판결이 뒤집혔는데, 오라클은 다시 항소할 뜻을 밝혔다.

※ 2017.01.20 : Wikipedia 내용이 많이 바뀌어서 다시 번역을 했습니다.

끝.