IT의 중심에서

기술은 사람을 행복하게 할 때 가장 아름다워진다.

API의 정의

API가 무엇인지 다들 알고 있지만 그렇다고 똑 부러지게 “이거다.”라고 이야기하는 사람도 없습니다. 그 이유는 API라는 용어가 포괄적으로 사용되어지고 있기 때문입니다. wikipedia를 번역하여, 내용의 이해를 돕고자 합니다.

api1

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

01. API의 정의

In computer programming, an application programming interface (API) is a set of subroutine definitions, protocols, and tools for building application software. In general terms, it’s a set of clearly defined methods of communication between various software components.

API는 어플리케이션을 만들기 위한 하위 함수, 프로토콜, 도구들의 집합들을 말한다. 즉 명확하게 정의된 다양한 컴포넌트들간의 통신 방법이다. 좋은 API 는 프로그래머들이 빌딩 블럭을 쌓듯이 쉽게 소프트웨어를 개발할 수 있도록 도와준다. 그래서 OS, DB, HW, SW library, Web 기반 시스템 등 다양한 곳에서 만들어진다. 그리고 루틴, 데이터 구조, object class, 변수, 리모트 호출 등 여러가지 스펙으로도 만들어진다. MS Window API, Java API 등은 API 의 다양한 모습이다. API의 지적재산권은 아직 토론의 여지가 많다.

02. 목적

GUI 가 일반인들이 프로그램을 사용하기 쉽게 만들어 준다면, API 는 프로그래머가 특정 기술을 사용하기 쉽게 만들어준다. 개발자들에게 필요한 기능들을 추상화하고, object, class 등을 제공함으로써 인지부하를 줄여주기도 한다. 예를 들어 이메일 프로그램이 메일을 작성하고 보내는 ‘버튼’을 일반인들에게 제공한다면,  파일 API는 OS나 파일시스템에 상관없이 파일을 복사하고 전송하는 ‘기능’을 프로그래머들에게 제공해준다.

03. 사용방법

가. library와 framework

API는 Software Library 와 관계가 있다.  library 가 실제 구현이라면, 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 라고 할 수 있다.

다. 리모트 API

리모트 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 에 대한 권리를 얻은 것은 전혀 없었다.

담당 판사였던 윌리엄은 API 는 미국 내에서는 저작권이 인정될 수 없으며 오라클이 저작권 보호를 과대 해석했다고 판결을 내렸다. 그리고 단지 소프트웨어 명령어에 대한 저작권만을 인정했다.

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

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

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


 

▲ 페이스북 페이지를 만들었습니다. 좀 더 작고 짧은 이야기들을 많이 올리려고 합니다. 많은 관심 부탁드립니다. : https://www.facebook.com/daddy4house/

API의 정의”에 대한 2개의 댓글

  1. 양명길
    2015년 12월 29일

    aip개념이 힘들었는데 감사합니다 ^^

    • subokim
      2015년 12월 29일

      별말씀을…피드백 감사드립니다.

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중

정보

이 엔트리는 2011년 12월 13일에 님이 API와 기술에 게시하였으며 , 태그가 지정되었습니다.

내비게이션

누적 조회수

  • 931,358 Visits

페이스북 페이지

%d 블로거가 이것을 좋아합니다: