API: 두 판 사이의 차이

잔글 (HotCat을 사용해서 분류:API을(를) 추가함)
(→‎소개: 이 무슨 외국어 직역...)
6번째 줄: 6번째 줄:
== 소개 ==
== 소개 ==
  [[파일:API.png|섬네일]]
  [[파일:API.png|섬네일]]
API를 해석하자면 Application Programming Interface, 즉 프로그램을 제작할 때, 그래픽카드나 네트워크카드, 운영체제, 파일같은 프로그램 밖에 있는 것들에 접근하기 위해서 만들어진 함수와 구조체, 혹은 클래스의 집합을 말한다.
API는 해당 함수나 클래스가 어떠한 동작을 하는 지를 프로그래머에게 공개한다. 이를 사양(Specification)이라고 한다. 그러면 프로그래머는 이 사양을 보고 프로그램을 제작한다. 해당 함수나 클래스에서 실제로 무슨 일을 하는지는 신경쓰지 않아도 된다. 따라서 API를 추상화 API라고 부른다.


프로그래밍에서, 프로그램을 작성하기 위한 일련의 부 프로그램, 프로토콜 등을 정의하여 하드웨어, 운영체제, 또는 다른 API와 상호 작용을 하기 위한 인터페이스 사양이다. 상호작용을 하는 대상은 그래픽 카드, 네트웍 장치와 같은 하드웨어, 운영체제, 또는 다른 응용 프로그램이 된다. API는 기능(Function, Method, Operation 으로 불리는 그것이다), 입력, 출력, 그리고 이에 사용되는 자료형으로 표현된다. API 자체는 어디까지사 "사양(Specification)"만을 정의하기 때문에 구현(Implementation)과 독립적이다. 잘 설계된 API는 프로그램 개발을 보다 쉽게 해준다. API는 제어 대상과 언어에 따라 다양한 형태로 존재하며, 유닉스의 POSIX 표준, 윈도우의 MFC나 Win32, C++의 Standard Template Library(STL), Java API 등이 이에 해당한다.
대표적으로 DirectX의 경우 엔비디아의 그래픽카드든, AMD의 그래픽카드든 프로그래머는 (이론상) 신경쓰지 않고 DirectX의 클래스와 함수만을 호출하여 화면에 3D모델을 그릴 수 있다.
 
대표적인 API는 유닉스의 POSIX 표준, 윈도우의 MFC나 Win32, DirectX, OpenGL, C++의 Standard Template Library(STL), Java API 등이 있다.


== API의 예 ==
== API의 예 ==

2016년 10월 24일 (월) 21:12 판


Application Programming Interface 의 약자.

소개

API.png

API를 해석하자면 Application Programming Interface, 즉 프로그램을 제작할 때, 그래픽카드나 네트워크카드, 운영체제, 파일같은 프로그램 밖에 있는 것들에 접근하기 위해서 만들어진 함수와 구조체, 혹은 클래스의 집합을 말한다. API는 해당 함수나 클래스가 어떠한 동작을 하는 지를 프로그래머에게 공개한다. 이를 사양(Specification)이라고 한다. 그러면 프로그래머는 이 사양을 보고 프로그램을 제작한다. 해당 함수나 클래스에서 실제로 무슨 일을 하는지는 신경쓰지 않아도 된다. 따라서 API를 추상화 API라고 부른다.

대표적으로 DirectX의 경우 엔비디아의 그래픽카드든, AMD의 그래픽카드든 프로그래머는 (이론상) 신경쓰지 않고 DirectX의 클래스와 함수만을 호출하여 화면에 3D모델을 그릴 수 있다.

대표적인 API는 유닉스의 POSIX 표준, 윈도우의 MFC나 Win32, DirectX, OpenGL, C++의 Standard Template Library(STL), Java API 등이 있다.

API의 예

그래픽 카드나 사운드 카드 등의 하드웨어 또는 데이터베이스를 조작할 때, API 는 작업을 편리하게 해준다. 실제로는 기계어 수준에서 이러한 작업이 수행되지만, API 로 프로그래머가 사용하기 편리하게 기능을 정리하여 제공하기 때문에 보다 쉽게 프로그램을 작성할 수 있다.

프로그램에 플러그인 형태로 설계된 API가 적용되면 , 이미 작성되어 컴파일되고 완성된 프로그램의 수정 없이 프로그램의 기능을 추가하는 것이 가능하다. 인터넷 익스플로러, 파이어폭스, 크롬과 같은 웹 브라우저 프로그램의 플러그인, 애드온과 같은 것이 바로 이러한 형식의 플러그인 API를 사용해 구현된 것이다.

원격의 컴퓨터에 기능을 수행할 수 있도록 해주는 SOAP 또는 RESTful 서비스에서 API는 그 자체로 원격 기능에 대한 사양(Specification)이 된다.

명령어 창(MS-DOS 쉘, 윈도우의 cmd.exe, 또는 유닉스/리눅스의 *Term 터미널 프로그램, OS X의 Terminal)에 "Hello, World!" 라는 문자열을 출력하는 프로그램을 C언어로 작성한다고 하자. 당연히 텍스트로 출력하는 printf API를 사용하여 printf("Hello, World!\n"); 라고 작성하게 될 것이며, 이는 윈도우, 리눅스, 유닉스, OS X 모두에서 동일하게 동작하도록 C언어 API가 보장해준다. 프로그래머는 보다 저수준에서 어떠한 일이 일어나는지 전혀 알지 못해도, 이미 정의된 printf를 사용하기만 하면 편리하게 텍스트를 출력할 수 있다

API와 라이브러리, ABI, SDK, 프레임웍의 차이

API 는 프로그래밍에 사용될 것을 전제로 설계되어 소스 코드 수준에서 정의되는 인터페이스다. 이와는 달리 기계어 이진 바이너리 수준에서 정의되는 이러한 인터페이스를 Application Binary Interface(ABI)라고 한다. API 자체는 구현물인 라이브러리와 독립적인 관계에 있다.

라이브러리는 실제로 동작할 수 있는 기계어로 된 단편화된 프로그램의 모음이라는 점에서 API와 다르다. 라이브러리 자체는 API 가 없이 존재할 수 있고, 이미 구현되어 기계어로 컴파일된 프로그램에 의해 사용될 수 있다. 이미 구현된 라이브러리와 기계어로 번역된 프로그램 사이의 인터페이스 사양은 Application Binary Interface(ABI)라고 한다.

유닉스는 애초에 C언어로 개발되었기 때문에, 당연히 C언어를 위한 API가 기본으로 제공된다. MS-DOS는 그렇지 않았기 때문에, 특정 언어를 위한 API 같은 것은 존재하지 않았고, 기계어(또는 어셈블리어) 수준에서 소프트웨어 인터럽트를 제공했다. MS-DOS의 이러한 방식을 지금의 관점에서 보면, ABI를 정의한 것으로 볼 수 있다.

프로그래밍을 해서 프로그램을 작성할 때 사용되는 것을 목적으로 하는 것이 아닌, 이미 작성된 프로그램을 실행하는 것이 목적이라면 API 없이 라이브러리만 필요하게 된다. 이와 같이 API 없이 실행하는데 필요한 라이브러리만 배포되는 대표적인 경우로 "Visual C++ Runtime Library", "DirectX Runtime"이 있다.

프레임웍은 명확하게 정의된 API가 존재한다는 점에서 API와 비슷하나, 일반적인 API는 전체 제어 구조를 사용하는 쪽에서 원하는대로 진행할 수 있지만, 프레임웍에서는 그럴 수 없는 경우가 많다는 점이 다르다.