위키원
"API"의 두 판 사이의 차이
hangyuwon95 (토론 | 기여) (→운영체제) |
잔글 |
||
| (사용자 4명의 중간 판 22개는 보이지 않습니다) | |||
| 1번째 줄: | 1번째 줄: | ||
| − | '''API'''(에이피아이)란 Application Programming | + | '''API'''(에이피아이)란 "Application Programming Interface"의 약자로서, 하나의 응용 프로그램이 다른 [[응용 프로그램]]에 요청을 보내고 응답을 받을 수 있도록 [[운영체제]]나 [[프로그래밍]] 언어가 제공하는 기능을 제어할 수 있게 만든 [[인터페이스]](I/F)를 말한다. '''응용 프로그램 인터페이스''' 또는 '''애플리케이션 프로그래밍 인터페이스'''라고 한다. |
| + | |||
==개요== | ==개요== | ||
| − | + | '''API'''라는 용어는 1968년에 출판된 원격 컴퓨터 그래픽을 위한 데이터 구조 및 기술인 Ira W. Cotton의 기사에서 처음 등장했다. 프로그래밍에서, 프로그램을 작성하기 위한 일련의 부 프로그램, 프로토콜 등을 정의하여 상호 작용을 하기 위한 [[인터페이스]] 사양을 말한다. API는 소프트웨어 [[컴포넌트]](Function, Method, Operation으로 불리는 그것이다)의 기능, 입력, 출력, 그리고 이에 사용되는 자료형으로 표현된다. API 자체는 어디까지나 사양(Specification)만을 정의하기 때문에 구현(Implementation)과는 독립적이다. 잘 설계된 API는 프로그램 개발을 보다 쉽게 해 준다. API는 다양한 형태로 존재하며, 유닉스의 [[POSIX]] 표준, 윈도우의 MFC나 Win32, C++의 표준 템플릿 라이브러리 (STL), Java SE API 등이 이에 해당한다. 예를 들어 그래픽 카드나 디스크 드라이브 등의 하드웨어 또는 데이터베이스를 조작할 때, API는 작업을 편리하게 해준다. 대개 실제로는 밑바닥에서 매우 저수준으로 이러한 작업이 수행되는데, API는 이러한 작업들에 대한 기능을 대상이 되는 언어에 맞게 추상화하고 프로그래머가 사용하기 편리하게 설계한 인터페이스 사양이다. | |
프로그램에 플러그인 형태로 설계된 API가 적용되면, 이미 작성되어 컴파일되고 완성된 프로그램의 수정 없이 프로그램의 기능을 추가하는 것이 가능하다. 인터넷 익스플로러, 파이어폭스, 크롬과 같은 웹 브라우저 프로그램의 플러그인, 애드온과 같은 것이 바로 이러한 형식의 플러그인 API를 사용해 구현된 것이다. | 프로그램에 플러그인 형태로 설계된 API가 적용되면, 이미 작성되어 컴파일되고 완성된 프로그램의 수정 없이 프로그램의 기능을 추가하는 것이 가능하다. 인터넷 익스플로러, 파이어폭스, 크롬과 같은 웹 브라우저 프로그램의 플러그인, 애드온과 같은 것이 바로 이러한 형식의 플러그인 API를 사용해 구현된 것이다. | ||
| − | API가 실제 기능 구현체인 라이브러리와 함께 제공되는 경우도 있으며, 이 경우를 SDK(Software Development Kit)라고 한다. SDK는 일반적으로 API, 라이브러리와 함께 프로그램을 개발하는데 필요한 여러 보조 프로그램을 포함한다. 원격의 컴퓨터에 기능을 수행할 수 있도록 해주는 SOAP 또는 RESTful 서비스에서 API는 그 자체로 원격 기능에 대한 사양(Specification)이 된다. | + | |
| − | 예를 들어 명령어 | + | API가 실제 기능 구현체인 라이브러리와 함께 제공되는 경우도 있으며, 이 경우를 [[SDK]](Software Development Kit)라고 한다. SDK는 일반적으로 API, 라이브러리와 함께 프로그램을 개발하는데 필요한 여러 보조 프로그램을 포함한다. 원격의 컴퓨터에 기능을 수행할 수 있도록 해주는 SOAP 또는 RESTful 서비스에서 API는 그 자체로 원격 기능에 대한 사양(Specification)이 된다. 예를 들어 명령어 창에 "Hello, World!" 라는 문자열을 출력하는 프로그램을 C언어로 작성한다고 하자. 당연히 텍스트로 출력하는 printf API를 사용하여 printf("Hello, World!\n"); 라고 작성하게 될 것이며, 이는 윈도우, 리눅스, 유닉스, OS X 모두에서 동일하게 동작하도록 C언어 API가 보장해준다. 프로그래머는 보다 저수준에서 어떠한 일이 일어나는지 알지 못해도, 이미 정의된 [[printf]]를 사용하기만 하면 편리하게 텍스트를 출력할 수 있다. 즉 잘 설계된 인터페이스를 사용하면 환경(플랫폼)이 달라져도 동일한 코드가 동일한 결과를 수행하며, 보다 편리하게 프로그래밍을 할 수 있다. |
| − | 한마디로, API는 소스 코드 수준에서 정의되는 | + | |
| − | 라이브러리는 실제로 동작할 수 있는 단편화된 프로그램이라는 점에서 API와 다르다. 라이브러리 자체는 API가 없이 존재할 수 있고, 이미 구현되어 기계어로 컴파일된 프로그램에 의해 사용될 수 있다. 이미 구현된 라이브러리와 프로그램 사이의 인터페이스 사양 또한 ABI이다. API 없이 프로그램을 실행하는데 필요한 라이브러리만 배포되는 대표적인 경우로 "Visual C++ Runtime Library", "DirectX Runtime"이 있다. 유닉스는 애초에 C언어로 개발되었기 때문에, 당연히 C언어를 위한 API가 기본으로 제공된다. MS-DOS는 그렇지 않았기 때문에 특정 언어를 위한 API 같은 것은 존재하지 않았고, 기계어(또는 어셈블리어) 수준에서 소프트웨어 인터럽트를 제공했다. MS-DOS의 이러한 방식을 지금의 관점에서 보면, ABI를 정의한 것으로 볼 수 있다. | + | 한마디로, API는 소스 코드 수준에서 정의되는 인터페이스이다. 이와는 달리 기계어 이진 바이너리 수준에서 정의되는 이러한 인터페이스는 ABI(Application Binary Interface)라고 한다. 라이브러리는 실제로 동작할 수 있는 단편화된 프로그램이라는 점에서 API와 다르다. 라이브러리 자체는 API가 없이 존재할 수 있고, 이미 구현되어 기계어로 컴파일된 프로그램에 의해 사용될 수 있다. 이미 구현된 라이브러리와 프로그램 사이의 인터페이스 사양 또한 ABI이다. API 없이 프로그램을 실행하는데 필요한 라이브러리만 배포되는 대표적인 경우로 "Visual C++ Runtime Library", "DirectX Runtime"이 있다. 유닉스는 애초에 C언어로 개발되었기 때문에, 당연히 C언어를 위한 API가 기본으로 제공된다. MS-DOS는 그렇지 않았기 때문에 특정 언어를 위한 API 같은 것은 존재하지 않았고, 기계어(또는 어셈블리어) 수준에서 소프트웨어 인터럽트를 제공했다. MS-DOS의 이러한 방식을 지금의 관점에서 보면, ABI를 정의한 것으로 볼 수 있다. 프레임워크는 명확하게 정의된 라이브러리가 존재한다는 점에서 API와 비슷하지만, 일반적인 API는 전체 제어 구조를 호출하는 쪽에서 원하는대로 진행할 수 있지만, 프레임워크에서는 그럴 수 없는 경우가 많다는 점이 다르다. <ref> |
| − | 프레임워크는 명확하게 정의된 라이브러리가 존재한다는 점에서 API와 비슷하지만, 일반적인 API는 전체 제어 구조를 호출하는 쪽에서 원하는대로 진행할 수 있지만, 프레임워크에서는 그럴 수 없는 경우가 많다는 점이 다르다. <ref> | ||
〈[https://namu.wiki/w/API API]〉, 《나무위키》</ref> | 〈[https://namu.wiki/w/API API]〉, 《나무위키》</ref> | ||
==등장배경== | ==등장배경== | ||
| − | + | 프로그램을 하면 더 복잡한 함수를 코딩해야하는 문제에 맞닥뜨릴수 있다.프로그래밍 함수를 사용하면 복잡한 코딩을 줄일 수 있으나. 반복해서 사용할경우에 불편한 경우가 있다. | |
| − | + | 똑같은 함수를 다시 만들 필요 없이 원하는 기능의 [[라이브러리]] 함수를 사용함으로써 보다 편하고 효율적인 프로그래밍이가능하다. 이러한 필수적인 [[라이브러리]]에 접근하기 위해서 API가 필요하다. | |
| − | + | ||
| − | |||
==운영체제== | ==운영체제== | ||
| − | API는 | + | API는 [[어플리케이션]]과 [[운영체제]]를 연결해주기도 한다. 예를 들어 [[POSIX]] 는 어플리케이션이 운영체제들과 통신하기 위한 공통 API규격들을 제공하고 있다. 이를 구현한 대표적인 사례로 Linux 와 버클리 재단이 있다. MS 도 호환 API의 대표 주자이다. 비록 윈도우에 한정되어서지만, 그들은 API를 이용해서 거의 완벽하게 하위 호환성을 지원하고 있기 때문이다. 그런데, API는 소스코드를 제공한다는 측면에서 ABI (binary) 와는 차이가 있다. 예를 들어 [[POSIX]] 는 API이지만, [[Linux]] 는 ABI 라고 할 수 있다.<ref>김수보, 〈[https://subokim.wordpress.com/2011/12/13/api-definition/ API의 정의]〉, 《월드 프레스》</ref> |
| − | 예를 들어 POSIX 는 어플리케이션이 운영체제들과 통신하기 위한 공통 API규격들을 제공하고 있다. | + | |
| − | 이를 구현한 대표적인 사례로 Linux 와 버클리 재단이 있다. | + | == 종류 == |
| − | MS 도 호환 API의 대표 주자이다. | + | * '''[[오픈 API]]'''(Open API) : 누구나 사용할 수 있도록 공개된 API를 말한다. [[구글]]이나 [[네이버]]의 지도 서비스 등이 있다. |
| − | 비록 윈도우에 한정되어서지만, 그들은 API를 이용해서 거의 완벽하게 하위 호환성을 지원하고 있기 때문이다. | + | * '''[[프라이빗 API]]'''(Private API) : 같은 기관 내부에서 근무하는 사람 또는 제한적으로 허용된 외부인이 사용할 수 있는 API를 말한다. |
| − | 그런데, API는 소스코드를 제공한다는 측면에서 ABI (binary) 와는 차이가 있다. | + | * '''[[윈도우 API]]'''(Win API) : [[윈도우]](Windows) 운영체제들이 사용하는 API다. [[C]]/[[C++]] 프로그램에서 직접 운영 체제와 상호 작용할 수 있도록 만들어졌으며, 그보다 더 낮은 수준의 제어는 Ntdll.dll을 사용한 낮은 수준의 DLL로 가능하다. |
| − | 예를 들어 POSIX 는 | + | *'''[[자바 API]]'''(Java API) : [[자바]]를 사용하여 쉽게 구현가능한 [[클래스]]계층구조로 된 라이브러리의 집합이다. |
| − | <ref> | + | * '''[[신디케이션 API]]'''(Syndication API) : 콘텐츠를 보유하고 있는 [[웹사이트]]와 [[네이버]] 등 [[검색엔진]] 사이에 동기화 규약을 정하는 API이다. 특정 [[웹사이트]]에서 신디케이션 API를 사용할 경우 문서의 생성, 수정, 삭제 현황을 검색엔진에 즉시 알려줄 수 있다. 이에 따라 [[검색엔진]] 로봇이 해당 웹사이트에 방문할 때까지 기다리지 않고 신속하게 콘텐츠 변경 현황을 검색 포털 사이트에 반영할 수 있다. [[웹개방성]]을 위한 핵심 기술의 하나이다. |
| − | 김수보, 〈[https://subokim.wordpress.com/2011/12/13/api-definition/ API의 정의]〉, 《월드 프레스》</ref> | ||
| − | ==특징 | + | ==특징== |
| − | + | ===정책=== | |
| − | + | API는 기술 회사가 서로 통합하는 가장 일반적인 방법 중 하나이다. API를 제공하고 사용하는 것은 비즈니스 생태계의 구성원으로 간주된다. API 공개를 위한 주요 정책은 다음과 같다. | |
| − | |||
| − | |||
| − | + | *비공개 : API는 내부 회사 전용이다. | |
| − | * | + | *파트너 : 특정 비즈니스 파트너 만 API를 사용할 수 있다. 예를 들어, Uber 및 Lyft 와 같은 운송 네트워크 회사에서는 승인된 타사 개발자가 앱 내에서 직접 차량을 주문할 수 있다. 이를 통해 회사는 API에 액세스할 수 있는 앱을 선별하여 품질 관리를 수행하고 추가 수익원을 제공할 수 있다. |
| − | + | *공개 : API는 공개적으로 사용할 수 있다. 예를 들어, 마이크로소프트는 마이크로소프트 API를 공개하고 애플은 자사의 플랫폼 용 소프트웨어를 작성할 수 있도록 API 카본(Carbon) 및 코코아(Cocoa)를 출시한다. | |
| − | + | ||
| − | * | + | * 공개 API 시사점 |
| − | + | : API가 공개될 때 중요한 요소는 "인터페이스 안정성"이다. 함수 호출에 새 매개 변수를 추가하는 등 개발자가 일부로 변경하면 해당 API에 의존하는 클라이언트와의 호환성이 손상될 수 있다. 공개적으로 제시된 API의 일부가 변경되어 불안정한 경우, 특정 API의 해당 부분은 명시 적으로 "불안정한"것으로 문서화되어야 한다. 예를 들어 구글 (Google Guava) 라이브러리에서 불안정한 것으로 간주되어 가까운 시일 내에 변경될 수 있는 부분은 자바([[Java]]) 주석으로 표시된다. 퍼블릭 API는 때때로 그 일부를 사용되지 않거나 폐기된 것으로 선언할 수 있다. 이는 일반적으로 API의 일부가 이전 버전과 호환되지 않는 방식으로 제거되거나 수정될 후보로 간주되어야 함을 의미한다. 따라서 이러한 변경을 통해 개발자는 향후 제거되거나 지원되지 않을 API 부분에서 전환할 수 있다. 클라이언트 코드에는 API디자이너가 의도하지 않은 혁신적이거나 기회적인 사용법이 포함될 수 있다. 즉, 사용자 기반이 중요한 라이브러리의 경우 요소가 공용 API의 일부가 되면 다양한 방식으로 사용될 수 있다. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | API를 | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | API는 | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | == | + | ===문서=== |
| − | + | API 설명서는 API가 제공하는 서비스와 해당 서비스를 사용하는 방법을 설명하며 고객이 실제 목적으로 알아야 할 모든 것을 포괄한다. API를 사용하여 애플리케이션을 개발하고 유지 보수하는 데 문서화가 중요하다. API 문서는 일반적으로 문서 파일에서 찾을 수 있지만 블로그, 포럼 및 Q & A 웹 사이트와 같은 소셜 미디어에서도 찾을 수 있다. 전통적인 문서 파일은 종종 모양과 구조가 일관된 자바독([[Javadoc]]) 또는 파이독([[Pydoc]])과 같은 문서 시스템을 통해 제공된다. 그러나 설명서에 포함된 내용 유형은 API마다 다르다. 명확성을 기하기 위해 API 문서에는 API의 [[클래스]] 및 [[메소드]]에 대한 설명과 "일반적인 사용 시나리오, 코드 스 니펫, 설계 이론적 근거, 성능 토론 및 계약"이 포함될 수 있지만 API 서비스 자체의 구현 세부 사항은 일반적으로 생략했다. | |
| − | + | API 사용 방법에 대한 제한 사항 및 제한 사항도 문서에서 다르다. 예를 들어, API 함수에 대한 문서는 함수 자체가 되지 않도록, 매개 변수가 널(null) 일 수 없다. 수 스레드 안전 , 또는 감소하는 자기거래를 피한다 프로토콜을 취소할 수 있습니다. [ 설명 필요 ] API 문서는 포괄적인 경향이 있으므로 작성자가 문서를 업데이트한 상태로 유지하고 사용자가 주의 깊게 읽으면 버그가 발생할 수 있다. API 주석은 Java 주석 과 같은 메타 데이터 정보로 보강될 수 있다 . 이 메타 데이터는 컴파일러, 도구 및 런타임 환경에서 사용자 지정 동작 또는 사용자 지정 처리를 구현 하는 데 사용할 수 있다. 데이터 기반 방식으로 API 문서를 생성할 수 있습니다. 주어진 API를 사용하는 많은 수의 프로그램을 관찰함으로써 일반적인 사용법과 필요한 계약 및 지침을 유추할 수 있습니다. 그 후, 템플릿은 채취된 데이터로부터 자연 언어를 생성하는데 사용될 수 있다. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | ==디자인== | + | ===디자인=== |
API 디자인은 사용에 상당한 영향을 미민다. 정보 숨기기 의 원칙은 모듈 사용자가 모듈 내부의 복잡성을 이해할 필요가 없도록 모듈의 구현 세부 사항을 숨겨 모듈 식 프로그래밍 을 가능하게 하는 프로그래밍 인터페이스의 역할을 설명합니다. 따라서, API의 디자인은 사용자가 기대할 수 있는 유일한 도구를 제공하려고 한다. 프로그래밍 인터페이스의 설계 는 복잡한 소프트웨어를 구성하는 소프트웨어 아키텍처 의 중요한 부분을 나타낸다 . | API 디자인은 사용에 상당한 영향을 미민다. 정보 숨기기 의 원칙은 모듈 사용자가 모듈 내부의 복잡성을 이해할 필요가 없도록 모듈의 구현 세부 사항을 숨겨 모듈 식 프로그래밍 을 가능하게 하는 프로그래밍 인터페이스의 역할을 설명합니다. 따라서, API의 디자인은 사용자가 기대할 수 있는 유일한 도구를 제공하려고 한다. 프로그래밍 인터페이스의 설계 는 복잡한 소프트웨어를 구성하는 소프트웨어 아키텍처 의 중요한 부분을 나타낸다 . | ||
몇몇 저자들은 Joshua Bloch , Kin Lane, 및 Michi Henning과 같은 API 설계 방법에 대한 권장 사항을 작성했다. 원격 API의 디자인과 진화 패턴은 일련의 EuroPLoP 논문에서 다룬다. | 몇몇 저자들은 Joshua Bloch , Kin Lane, 및 Michi Henning과 같은 API 설계 방법에 대한 권장 사항을 작성했다. 원격 API의 디자인과 진화 패턴은 일련의 EuroPLoP 논문에서 다룬다. | ||
| − | |||
| − | == | + | ===API 개선=== |
| − | + | * 클라이언트 서버 아키텍처 : REST 아키텍처가 클라이언트, 서버, 리소스로 구성되며 [[HTTP]]를 통해 요청을 처리한다. | |
| − | API | + | * 스테이트리스 : 요청이 통과하는 서버에는 클라이언트 콘텐츠가 저장되지 않으며 그 대신 세션 상태에 대한 정보가 클라이언트에 저장한다. |
| − | * | + | * 캐시 가능성 : 캐싱으로 일부 클라이언트-서버 간의 상호 작용이 제거된다. |
| − | * | + | * 계층화된 시스템 : 추가 계층으로 클라이언트-서버 간의 상호 작용을 조정할 수 있으며 이러한 계층은 로드 밸런싱, 공유 캐시 또는 보안과 같은 추가 기능을 제공할 수 있다. |
| − | + | * 코드 온디맨드(옵션) : 서버가 실행 가능한 코드를 전송하여 클라이언트의 기능을 확대할 수 있다. | |
| − | === | + | * 통합된 인터페이스 : 이 제약 조건은 [[RESTful]] API 설계의 핵심이며 다음과 같은 4가지 측면을 포함한다. |
| − | + | * 요청에서 리소스 식별 : 리소스가 요청에서 식별되며 클라이언트로 반환된 표현으로부터 분리된다. | |
| − | + | * 표현을 통한 리소스 조작 : 클라이언트가 리소스를 나타내는 파일을 수신합니다. 이 표현에는 조작 또는 삭제를 허용할 수 있도록 충분한 양의 정보가 포함되어야 한다. | |
| − | + | * 자기 기술적(Self-descriptive) 메시지 : 클라이언트에 반환되는 각 메시지에 클라이언트가 정보를 어떻게 처리해야 할지 설명하는 정보가 충분히 포함되어야 한다. | |
| − | + | * 애플리케이션 상태 엔진으로서의 하이퍼미디어 : 리소스를 할당한 후 REST 클라이언트가 하이퍼링크를 통해 현재 사용 가능한 기타 모든 작업을 찾을 수 있어야 한다.<ref> | |
| + | 〈[https://www.redhat.com/ko/topics/api/what-are-application-programming-interfaces API란?]〉, 《레드햇》</ref> | ||
| + | |||
| + | ===저작권 문제=== | ||
| + | 2010년 [[오라클]](Oracle Corporation)은 [[안드로이드]](Android) 운영 체제에 내장된 새로운 [[자바]](Java) 구현을 배포한 결과 [[구글]]([[Google]])에 소송을 제기했다. 유사한 [[OpenJDK]] 프로젝트에 대한 권한이 부여되었지만, 구글은 Java API 재생산에 대한 권한을 얻지 못했다. William Alsup 판사는 오라클 대 구글의 경우 미국에서 API를 저작권으로 보호할 수 없으며 오라클의 승리로 저작권 보호가 광범위하게 확대되고 간단한 소프트웨어 명령의 저작권이 허용될 것이라고 판결했다 . "오라클의 주장을 받아들이려면 누구나 한 버전의 코드에 저작권을 부여하여 명령 시스템을 수행함으로써 다른 모든 사용자가 자체적으로 다른 버전을 작성하여 동일한 명령의 전부 또는 일부를 수행하지 못하게 해야 한다." 그러나 2014년에 [[Alsup]]의 판결은 연방 순회 항소 법원에 항소하여 전복되었지만 API의 사용이 공정 사용에 해당하는지에 대한 문제는 해결되지 않은 채 남아 있었다. 2016년 2주 동안의 재판 후, 배심원 단은 구글의 자바 API 재구현이 공정한 사용이라고 판단했지만 오라클은 이 결정에 항소할 것을 맹세했다. 오라클은 자사의 API 사용이 공정 사용에 적합하지 않다는 판결을 내린 연방 회로 항소 법원에 항소했다. 2019년 구글은 저작권 및 공정 사용 판결에 대해 미국 대법원에 항소했다. | ||
| + | |||
| + | ===장단점=== | ||
| + | * [[운영체제]](OS)가 제공하는 다양한 기능을 사용하게 해준다. | ||
| + | * [[라이브러리]]에서 필요한 함수를 골라서 사용하게 해준다. | ||
| + | * 운영체제(OS)를 제공하고 있는 메이커가 표준화한 API를 소프트하우스 등에 공개하면 주변 기기와의 인터페이스에 특히 주의하지 않아도 프로그램을 개발할 수 있고 애플리케이션 프로그램의 개발이 용이해진다. | ||
| + | * 처음 접해봤을 땐 어렵다. | ||
| + | |||
| + | ==활용== | ||
| + | ===라이브러리 및 프레임워크=== | ||
| + | API는 일반적으로 소프트웨어 [[라이브러리]]와 관련이 있다. [[라이브러리]]는 이 규칙 세트의 "실제 구현"인 반면 API는 "예상된 동작"(사양)을 설명하고 규정한다. 단일 API는 동일한 프로그래밍 인터페이스를 공유하는 서로 다른 라이브러리 형태로 여러 구현 (또는 추상이 아님)을 가질 수 있다. API를 구현에서 분리하면 한 언어로 작성된 프로그램이 다른 언어로 작성된 라이브러리를 사용할 수 있다. 예를 들어 [[스칼라 (프로그래밍)|스칼라]](Scala) 및 [[자바]]는 호환 가능한 [[바이트코드]](bytecode)로 [[컴파일]]되므로 스칼라 개발자는 모든 Java API를 활용할 수 있다. API 사용은 관련된 프로그래밍 언어의 유형에 따라 달라질 수 있다. [[루아]](Lua)와 같은 절차적 언어용 API는 기본적으로 코드 실행, 데이터 조작 또는 오류 처리를 위한 기본 루틴으로 구성될 수 있지만 자바와 같은 객체 지향 언어 용 API는 클래스 및 클래스 메소드의 스펙을 제공한다. | ||
| + | |||
| + | 언어 바인딩도 API이다. 한 언어의 기능을 다른 언어로 구현된 인터페이스에 매핑하면 언어 바인딩을 통해 한 언어로 작성된 라이브러리 나 서비스를 다른 언어로 개발할 때 사용할 수 있다. [[포트란]]-to-[[파이썬]] 인터페이스 생성기인 [[SWIG]] 및 [[F2PY]] 와 같은 도구는 이러한 인터페이스를 쉽게 만들 수 있다. API는 또한 소프트웨어 프레임워크와 관련될 수 있다. 프레임워크는 여러 API를 구현하는 여러 라이브러리를 기반으로 할 수 있지만 일반적인 API 사용과 달리 프레임워크에 내장된 동작에 대한 액세스는 콘텐츠를 새로운 클래스로 확장하여 조정됩니다 프레임워크 자체에 연결했다. 더욱이, 제어의 전체 프로그램 흐름은 제어의 역전 또는 유사한 메커니즘에 의해 호출자의 제어 및 프레임워크의 손에서 벗어날 수 있다. | ||
| + | |||
| + | ===운영체제=== | ||
| + | API는 응용 프로그램과 [[운영체제]] 사이의 [[인터페이스]]를 지정할 수 있다. POSIX는, 예를 들면, 하기 POSIX 준수 운영체제 작성된 응용 프로그램 활성화하고자 공통 API 세트를 지정 컴파일 다른 POSIX 준수 운영체제한다. Linux 및 Berkeley Software Distribution 은 POSIX API를 구현하는 운영 체제의 예이다. Microsoft는 특히 Windows API (Win32) 라이브러리 내에서 이전 버전과 호환되는 API에 대한 강력한 의지를 보였어 므로 이전 응용 프로그램은 "호환성 모드"라는 실행 파일 별 설정을 사용하여 최신 버전의 Windows에서 실행될 수 있다. API는 소스 코드 기반이고 ABI는 이진 기반이라는 점에서 API는 ABI ( Application Binary Interface) 와 다르다. 예를 들어 POSIX는 API를 제공하고 Linux Standard Base는 ABI를 제공한다. | ||
| + | |||
| + | ===원격 API=== | ||
| + | [[원격 API]]를 통해 개발자는 프로그래밍 언어 또는 플랫폼에 관계없이 서로 다른 기술이 함께 작동할 수 있도록 특정 통신 표준인 프로토콜을 통해 원격 리소스를 조작할 수 있다. 예를 들어, Java Database Connectivity API를 사용하면 개발자는 동일한 기능 세트로 여러 유형의 데이터베이스를 조회할 수 있으며 자바원격 메소드 호출 API는 자바원격 메소드 프로토콜을 사용하여 원격으로 작동하지만 로컬로 표시되는 함수의 호출을 허용한다. 따라서 원격 API는 객체 지향 프로그래밍에서 객체 추상화를 유지하는 데 유용하다. 프락시 객체에서 로컬로 실행되는 메소드 호출은 원격 프로토콜을 사용하여 원격 객체에서 해당 메소드를 호출하고 결과를 로컬로 반환 값으로 사용한다. 프락시 개체를 수정하면 원격 개체도 해당 수정된다. | ||
| + | |||
| + | ===웹 API=== | ||
| + | [[웹 API]]는 기능 제공자를 지정하고 API 사용자의 서비스 경로 또는 [[URL]]을 공개하기 위한 [[SLA]](Service Level Agreement)인 자산을 사용하는 엔터프라이즈와 애플리케이션 간에 상호 작용이 발생하도록 정의된 인터페이스이다. API 접근 방식은 여러 유형의 소비자에게 서비스를 제공하는 다른 응용 프로그램에 일련의 서비스에 대한 프로그램 인터페이스를 제공하는 것을 중심으로 하는 아키텍처 접근 방식이다. 웹 개발의 맥락에서 사용될 때 API는 일반적으로 HTTP ( Hypertext Transfer Protocol) 요청 메시지 와 같은 일련의 사양으로 정의되며, 일반적으로 XML (Extensible Markup Language)로 응답 메시지 구조의 정의와 함께 정의됩니다. ) 또는 JavaScript 객체 표기법(JSON) 형식이다. 예를 들어, 전자상거래 중심의 웹 사이트에 추가하여 운송 서비스 주문을 용이하게 하고 사이트 개발자가 운송 업체의 요금 표를 웹 데이터베이스에 입력하지 않고도 현재 운송비를 자동으로 포함할 수 있는 운송 회사 API를 예로 들 수 있다. | ||
| − | + | [[웹 API]]는 역사적으로 사실상 [[웹서비스]]와 동의어였지만 최근 트렌드(웹 2.0)는 [[SOAP]](Simple Object Access Protocol) 기반 웹서비스 및 [[SOA]](Service-Oriented Architecture)에서 [[REST]](Representational Stateal State Transfer) 스타일 웹 자원 및 [[ROA]](Resource-Oriented Architecture)로 이동하고 있다. 이 추세의 일부는 웹 기반 [[온톨로지]] 엔지니어링 기술을 장려하는 개념인 [[RDF]](Resource Description Framework)를 향한 [[시맨틱웹]] 이동과 관련이 있다. 웹 API를 사용하면 여러 API를 [[매시업]]이라고 하는 새로운 응용 프로그램으로 결합할 수 있다. 소셜 미디어 공간에서 웹 API는 웹 커뮤니티가 커뮤니티와 애플리케이션 간에 콘텐츠 및 데이터 공유를 용이하게 한다. 이러한 방식으로 한 곳에서 동적으로 생성된 콘텐츠를 웹의 여러 위치에 게시하고 업데이트할 수 있다. 예를 들어, 트위터의 REST API는 개발자가 핵심 트위터 데이터에 액세스할 수 있다.<ref>〈[https://en.wikipedia.org/wiki/Application_programming_interface#History API]〉, 《위키피디아》</ref> | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
==전망== | ==전망== | ||
| − | *통신·방송·인터넷이 하나의 통합된 전달망을 기반으로 이들간 상호 융합된 서비스들을 제공할 수 있는 광대역 통합망으로 발전할 것이다. <ref>고안해 내는 재능,〈[http://egloos.zum.com/ingenuity/v/3751761 Open API (Application Program Interface)]〉, 《ZUM》,2007-09-05</ref> | + | * 통신·방송·인터넷이 하나의 통합된 전달망을 기반으로 이들간 상호 융합된 서비스들을 제공할 수 있는 광대역 통합망으로 발전할 것이다. <ref>고안해 내는 재능,〈[http://egloos.zum.com/ingenuity/v/3751761 Open API (Application Program Interface)]〉, 《ZUM》,2007-09-05</ref> |
| − | *금융감독원 기업공시국은 | + | |
| − | + | * [[금융감독원]] 기업공시국은 [[다트]](DART)의 오픈 API 정보제공 범위를 현재 기업개황 및 [[공시]] 목록에서 세부 공시 내용까지 확대해 21종을 추가 제공해서 공시 이용자가 DART 홈페이지에 방문하지 않아도 원하는 공시서류 원본 파일을 [[다운로드]]할 수 있고, 사업보고서 및 분·반기보고서 상에서 공시 이용자들이 관심을 가질 정보를 활용할 수 있게 될 전망이다.<ref>한수연 기자, 〈[http://www.inews24.com/view/1185219 공시 보기 편해진다…DART, 오픈API 제공 확대]〉, 《아이뉴스 24》,2009-06-11</ref> | |
| − | + | ||
| − | |||
| − | |||
| − | |||
{{각주}} | {{각주}} | ||
==참고자료== | ==참고자료== | ||
| − | *고안해 내는 재능,〈[http://egloos.zum.com/ingenuity/v/3751761 Open API (Application Program Interface)]〉, 《ZUM》,2007-09-05 | + | * 고안해 내는 재능, 〈[http://egloos.zum.com/ingenuity/v/3751761 Open API (Application Program Interface)]〉, 《ZUM》, 2007-09-05 |
| − | * 한수연 기자, 〈[http://www.inews24.com/view/1185219 공시 보기 편해진다…DART, 오픈API 제공 확대]〉, 《아이뉴스 24》,2009-06-11 | + | * 한수연 기자, 〈[http://www.inews24.com/view/1185219 공시 보기 편해진다…DART, 오픈API 제공 확대]〉, 《아이뉴스 24》, 2009-06-11 |
| + | * 〈[https://en.wikipedia.org/wiki/Application_programming_interface#History API]〉, 《위키피디아》 | ||
== 같이 보기 == | == 같이 보기 == | ||
| 123번째 줄: | 98번째 줄: | ||
* [[응용 프로그램]] | * [[응용 프로그램]] | ||
| − | {{ | + | {{시스템 연계|검토 필요}} |
2022년 6월 27일 (월) 23:41 기준 최신판
API(에이피아이)란 "Application Programming Interface"의 약자로서, 하나의 응용 프로그램이 다른 응용 프로그램에 요청을 보내고 응답을 받을 수 있도록 운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스(I/F)를 말한다. 응용 프로그램 인터페이스 또는 애플리케이션 프로그래밍 인터페이스라고 한다.
목차
개요[편집]
API라는 용어는 1968년에 출판된 원격 컴퓨터 그래픽을 위한 데이터 구조 및 기술인 Ira W. Cotton의 기사에서 처음 등장했다. 프로그래밍에서, 프로그램을 작성하기 위한 일련의 부 프로그램, 프로토콜 등을 정의하여 상호 작용을 하기 위한 인터페이스 사양을 말한다. API는 소프트웨어 컴포넌트(Function, Method, Operation으로 불리는 그것이다)의 기능, 입력, 출력, 그리고 이에 사용되는 자료형으로 표현된다. API 자체는 어디까지나 사양(Specification)만을 정의하기 때문에 구현(Implementation)과는 독립적이다. 잘 설계된 API는 프로그램 개발을 보다 쉽게 해 준다. API는 다양한 형태로 존재하며, 유닉스의 POSIX 표준, 윈도우의 MFC나 Win32, C++의 표준 템플릿 라이브러리 (STL), Java SE API 등이 이에 해당한다. 예를 들어 그래픽 카드나 디스크 드라이브 등의 하드웨어 또는 데이터베이스를 조작할 때, API는 작업을 편리하게 해준다. 대개 실제로는 밑바닥에서 매우 저수준으로 이러한 작업이 수행되는데, API는 이러한 작업들에 대한 기능을 대상이 되는 언어에 맞게 추상화하고 프로그래머가 사용하기 편리하게 설계한 인터페이스 사양이다. 프로그램에 플러그인 형태로 설계된 API가 적용되면, 이미 작성되어 컴파일되고 완성된 프로그램의 수정 없이 프로그램의 기능을 추가하는 것이 가능하다. 인터넷 익스플로러, 파이어폭스, 크롬과 같은 웹 브라우저 프로그램의 플러그인, 애드온과 같은 것이 바로 이러한 형식의 플러그인 API를 사용해 구현된 것이다.
API가 실제 기능 구현체인 라이브러리와 함께 제공되는 경우도 있으며, 이 경우를 SDK(Software Development Kit)라고 한다. SDK는 일반적으로 API, 라이브러리와 함께 프로그램을 개발하는데 필요한 여러 보조 프로그램을 포함한다. 원격의 컴퓨터에 기능을 수행할 수 있도록 해주는 SOAP 또는 RESTful 서비스에서 API는 그 자체로 원격 기능에 대한 사양(Specification)이 된다. 예를 들어 명령어 창에 "Hello, World!" 라는 문자열을 출력하는 프로그램을 C언어로 작성한다고 하자. 당연히 텍스트로 출력하는 printf API를 사용하여 printf("Hello, World!\n"); 라고 작성하게 될 것이며, 이는 윈도우, 리눅스, 유닉스, OS X 모두에서 동일하게 동작하도록 C언어 API가 보장해준다. 프로그래머는 보다 저수준에서 어떠한 일이 일어나는지 알지 못해도, 이미 정의된 printf를 사용하기만 하면 편리하게 텍스트를 출력할 수 있다. 즉 잘 설계된 인터페이스를 사용하면 환경(플랫폼)이 달라져도 동일한 코드가 동일한 결과를 수행하며, 보다 편리하게 프로그래밍을 할 수 있다.
한마디로, API는 소스 코드 수준에서 정의되는 인터페이스이다. 이와는 달리 기계어 이진 바이너리 수준에서 정의되는 이러한 인터페이스는 ABI(Application Binary Interface)라고 한다. 라이브러리는 실제로 동작할 수 있는 단편화된 프로그램이라는 점에서 API와 다르다. 라이브러리 자체는 API가 없이 존재할 수 있고, 이미 구현되어 기계어로 컴파일된 프로그램에 의해 사용될 수 있다. 이미 구현된 라이브러리와 프로그램 사이의 인터페이스 사양 또한 ABI이다. API 없이 프로그램을 실행하는데 필요한 라이브러리만 배포되는 대표적인 경우로 "Visual C++ Runtime Library", "DirectX Runtime"이 있다. 유닉스는 애초에 C언어로 개발되었기 때문에, 당연히 C언어를 위한 API가 기본으로 제공된다. MS-DOS는 그렇지 않았기 때문에 특정 언어를 위한 API 같은 것은 존재하지 않았고, 기계어(또는 어셈블리어) 수준에서 소프트웨어 인터럽트를 제공했다. MS-DOS의 이러한 방식을 지금의 관점에서 보면, ABI를 정의한 것으로 볼 수 있다. 프레임워크는 명확하게 정의된 라이브러리가 존재한다는 점에서 API와 비슷하지만, 일반적인 API는 전체 제어 구조를 호출하는 쪽에서 원하는대로 진행할 수 있지만, 프레임워크에서는 그럴 수 없는 경우가 많다는 점이 다르다. [1]
등장배경[편집]
프로그램을 하면 더 복잡한 함수를 코딩해야하는 문제에 맞닥뜨릴수 있다.프로그래밍 함수를 사용하면 복잡한 코딩을 줄일 수 있으나. 반복해서 사용할경우에 불편한 경우가 있다. 똑같은 함수를 다시 만들 필요 없이 원하는 기능의 라이브러리 함수를 사용함으로써 보다 편하고 효율적인 프로그래밍이가능하다. 이러한 필수적인 라이브러리에 접근하기 위해서 API가 필요하다.
운영체제[편집]
API는 어플리케이션과 운영체제를 연결해주기도 한다. 예를 들어 POSIX 는 어플리케이션이 운영체제들과 통신하기 위한 공통 API규격들을 제공하고 있다. 이를 구현한 대표적인 사례로 Linux 와 버클리 재단이 있다. MS 도 호환 API의 대표 주자이다. 비록 윈도우에 한정되어서지만, 그들은 API를 이용해서 거의 완벽하게 하위 호환성을 지원하고 있기 때문이다. 그런데, API는 소스코드를 제공한다는 측면에서 ABI (binary) 와는 차이가 있다. 예를 들어 POSIX 는 API이지만, Linux 는 ABI 라고 할 수 있다.[2]
종류[편집]
- 오픈 API(Open API) : 누구나 사용할 수 있도록 공개된 API를 말한다. 구글이나 네이버의 지도 서비스 등이 있다.
- 프라이빗 API(Private API) : 같은 기관 내부에서 근무하는 사람 또는 제한적으로 허용된 외부인이 사용할 수 있는 API를 말한다.
- 윈도우 API(Win API) : 윈도우(Windows) 운영체제들이 사용하는 API다. C/C++ 프로그램에서 직접 운영 체제와 상호 작용할 수 있도록 만들어졌으며, 그보다 더 낮은 수준의 제어는 Ntdll.dll을 사용한 낮은 수준의 DLL로 가능하다.
- 자바 API(Java API) : 자바를 사용하여 쉽게 구현가능한 클래스계층구조로 된 라이브러리의 집합이다.
- 신디케이션 API(Syndication API) : 콘텐츠를 보유하고 있는 웹사이트와 네이버 등 검색엔진 사이에 동기화 규약을 정하는 API이다. 특정 웹사이트에서 신디케이션 API를 사용할 경우 문서의 생성, 수정, 삭제 현황을 검색엔진에 즉시 알려줄 수 있다. 이에 따라 검색엔진 로봇이 해당 웹사이트에 방문할 때까지 기다리지 않고 신속하게 콘텐츠 변경 현황을 검색 포털 사이트에 반영할 수 있다. 웹개방성을 위한 핵심 기술의 하나이다.
특징[편집]
정책[편집]
API는 기술 회사가 서로 통합하는 가장 일반적인 방법 중 하나이다. API를 제공하고 사용하는 것은 비즈니스 생태계의 구성원으로 간주된다. API 공개를 위한 주요 정책은 다음과 같다.
- 비공개 : API는 내부 회사 전용이다.
- 파트너 : 특정 비즈니스 파트너 만 API를 사용할 수 있다. 예를 들어, Uber 및 Lyft 와 같은 운송 네트워크 회사에서는 승인된 타사 개발자가 앱 내에서 직접 차량을 주문할 수 있다. 이를 통해 회사는 API에 액세스할 수 있는 앱을 선별하여 품질 관리를 수행하고 추가 수익원을 제공할 수 있다.
- 공개 : API는 공개적으로 사용할 수 있다. 예를 들어, 마이크로소프트는 마이크로소프트 API를 공개하고 애플은 자사의 플랫폼 용 소프트웨어를 작성할 수 있도록 API 카본(Carbon) 및 코코아(Cocoa)를 출시한다.
- 공개 API 시사점
- API가 공개될 때 중요한 요소는 "인터페이스 안정성"이다. 함수 호출에 새 매개 변수를 추가하는 등 개발자가 일부로 변경하면 해당 API에 의존하는 클라이언트와의 호환성이 손상될 수 있다. 공개적으로 제시된 API의 일부가 변경되어 불안정한 경우, 특정 API의 해당 부분은 명시 적으로 "불안정한"것으로 문서화되어야 한다. 예를 들어 구글 (Google Guava) 라이브러리에서 불안정한 것으로 간주되어 가까운 시일 내에 변경될 수 있는 부분은 자바(Java) 주석으로 표시된다. 퍼블릭 API는 때때로 그 일부를 사용되지 않거나 폐기된 것으로 선언할 수 있다. 이는 일반적으로 API의 일부가 이전 버전과 호환되지 않는 방식으로 제거되거나 수정될 후보로 간주되어야 함을 의미한다. 따라서 이러한 변경을 통해 개발자는 향후 제거되거나 지원되지 않을 API 부분에서 전환할 수 있다. 클라이언트 코드에는 API디자이너가 의도하지 않은 혁신적이거나 기회적인 사용법이 포함될 수 있다. 즉, 사용자 기반이 중요한 라이브러리의 경우 요소가 공용 API의 일부가 되면 다양한 방식으로 사용될 수 있다.
문서[편집]
API 설명서는 API가 제공하는 서비스와 해당 서비스를 사용하는 방법을 설명하며 고객이 실제 목적으로 알아야 할 모든 것을 포괄한다. API를 사용하여 애플리케이션을 개발하고 유지 보수하는 데 문서화가 중요하다. API 문서는 일반적으로 문서 파일에서 찾을 수 있지만 블로그, 포럼 및 Q & A 웹 사이트와 같은 소셜 미디어에서도 찾을 수 있다. 전통적인 문서 파일은 종종 모양과 구조가 일관된 자바독(Javadoc) 또는 파이독(Pydoc)과 같은 문서 시스템을 통해 제공된다. 그러나 설명서에 포함된 내용 유형은 API마다 다르다. 명확성을 기하기 위해 API 문서에는 API의 클래스 및 메소드에 대한 설명과 "일반적인 사용 시나리오, 코드 스 니펫, 설계 이론적 근거, 성능 토론 및 계약"이 포함될 수 있지만 API 서비스 자체의 구현 세부 사항은 일반적으로 생략했다. API 사용 방법에 대한 제한 사항 및 제한 사항도 문서에서 다르다. 예를 들어, API 함수에 대한 문서는 함수 자체가 되지 않도록, 매개 변수가 널(null) 일 수 없다. 수 스레드 안전 , 또는 감소하는 자기거래를 피한다 프로토콜을 취소할 수 있습니다. [ 설명 필요 ] API 문서는 포괄적인 경향이 있으므로 작성자가 문서를 업데이트한 상태로 유지하고 사용자가 주의 깊게 읽으면 버그가 발생할 수 있다. API 주석은 Java 주석 과 같은 메타 데이터 정보로 보강될 수 있다 . 이 메타 데이터는 컴파일러, 도구 및 런타임 환경에서 사용자 지정 동작 또는 사용자 지정 처리를 구현 하는 데 사용할 수 있다. 데이터 기반 방식으로 API 문서를 생성할 수 있습니다. 주어진 API를 사용하는 많은 수의 프로그램을 관찰함으로써 일반적인 사용법과 필요한 계약 및 지침을 유추할 수 있습니다. 그 후, 템플릿은 채취된 데이터로부터 자연 언어를 생성하는데 사용될 수 있다.
디자인[편집]
API 디자인은 사용에 상당한 영향을 미민다. 정보 숨기기 의 원칙은 모듈 사용자가 모듈 내부의 복잡성을 이해할 필요가 없도록 모듈의 구현 세부 사항을 숨겨 모듈 식 프로그래밍 을 가능하게 하는 프로그래밍 인터페이스의 역할을 설명합니다. 따라서, API의 디자인은 사용자가 기대할 수 있는 유일한 도구를 제공하려고 한다. 프로그래밍 인터페이스의 설계 는 복잡한 소프트웨어를 구성하는 소프트웨어 아키텍처 의 중요한 부분을 나타낸다 . 몇몇 저자들은 Joshua Bloch , Kin Lane, 및 Michi Henning과 같은 API 설계 방법에 대한 권장 사항을 작성했다. 원격 API의 디자인과 진화 패턴은 일련의 EuroPLoP 논문에서 다룬다.
API 개선[편집]
- 클라이언트 서버 아키텍처 : REST 아키텍처가 클라이언트, 서버, 리소스로 구성되며 HTTP를 통해 요청을 처리한다.
- 스테이트리스 : 요청이 통과하는 서버에는 클라이언트 콘텐츠가 저장되지 않으며 그 대신 세션 상태에 대한 정보가 클라이언트에 저장한다.
- 캐시 가능성 : 캐싱으로 일부 클라이언트-서버 간의 상호 작용이 제거된다.
- 계층화된 시스템 : 추가 계층으로 클라이언트-서버 간의 상호 작용을 조정할 수 있으며 이러한 계층은 로드 밸런싱, 공유 캐시 또는 보안과 같은 추가 기능을 제공할 수 있다.
- 코드 온디맨드(옵션) : 서버가 실행 가능한 코드를 전송하여 클라이언트의 기능을 확대할 수 있다.
- 통합된 인터페이스 : 이 제약 조건은 RESTful API 설계의 핵심이며 다음과 같은 4가지 측면을 포함한다.
- 요청에서 리소스 식별 : 리소스가 요청에서 식별되며 클라이언트로 반환된 표현으로부터 분리된다.
- 표현을 통한 리소스 조작 : 클라이언트가 리소스를 나타내는 파일을 수신합니다. 이 표현에는 조작 또는 삭제를 허용할 수 있도록 충분한 양의 정보가 포함되어야 한다.
- 자기 기술적(Self-descriptive) 메시지 : 클라이언트에 반환되는 각 메시지에 클라이언트가 정보를 어떻게 처리해야 할지 설명하는 정보가 충분히 포함되어야 한다.
- 애플리케이션 상태 엔진으로서의 하이퍼미디어 : 리소스를 할당한 후 REST 클라이언트가 하이퍼링크를 통해 현재 사용 가능한 기타 모든 작업을 찾을 수 있어야 한다.[3]
저작권 문제[편집]
2010년 오라클(Oracle Corporation)은 안드로이드(Android) 운영 체제에 내장된 새로운 자바(Java) 구현을 배포한 결과 구글(Google)에 소송을 제기했다. 유사한 OpenJDK 프로젝트에 대한 권한이 부여되었지만, 구글은 Java API 재생산에 대한 권한을 얻지 못했다. William Alsup 판사는 오라클 대 구글의 경우 미국에서 API를 저작권으로 보호할 수 없으며 오라클의 승리로 저작권 보호가 광범위하게 확대되고 간단한 소프트웨어 명령의 저작권이 허용될 것이라고 판결했다 . "오라클의 주장을 받아들이려면 누구나 한 버전의 코드에 저작권을 부여하여 명령 시스템을 수행함으로써 다른 모든 사용자가 자체적으로 다른 버전을 작성하여 동일한 명령의 전부 또는 일부를 수행하지 못하게 해야 한다." 그러나 2014년에 Alsup의 판결은 연방 순회 항소 법원에 항소하여 전복되었지만 API의 사용이 공정 사용에 해당하는지에 대한 문제는 해결되지 않은 채 남아 있었다. 2016년 2주 동안의 재판 후, 배심원 단은 구글의 자바 API 재구현이 공정한 사용이라고 판단했지만 오라클은 이 결정에 항소할 것을 맹세했다. 오라클은 자사의 API 사용이 공정 사용에 적합하지 않다는 판결을 내린 연방 회로 항소 법원에 항소했다. 2019년 구글은 저작권 및 공정 사용 판결에 대해 미국 대법원에 항소했다.
장단점[편집]
- 운영체제(OS)가 제공하는 다양한 기능을 사용하게 해준다.
- 라이브러리에서 필요한 함수를 골라서 사용하게 해준다.
- 운영체제(OS)를 제공하고 있는 메이커가 표준화한 API를 소프트하우스 등에 공개하면 주변 기기와의 인터페이스에 특히 주의하지 않아도 프로그램을 개발할 수 있고 애플리케이션 프로그램의 개발이 용이해진다.
- 처음 접해봤을 땐 어렵다.
활용[편집]
라이브러리 및 프레임워크[편집]
API는 일반적으로 소프트웨어 라이브러리와 관련이 있다. 라이브러리는 이 규칙 세트의 "실제 구현"인 반면 API는 "예상된 동작"(사양)을 설명하고 규정한다. 단일 API는 동일한 프로그래밍 인터페이스를 공유하는 서로 다른 라이브러리 형태로 여러 구현 (또는 추상이 아님)을 가질 수 있다. API를 구현에서 분리하면 한 언어로 작성된 프로그램이 다른 언어로 작성된 라이브러리를 사용할 수 있다. 예를 들어 스칼라(Scala) 및 자바는 호환 가능한 바이트코드(bytecode)로 컴파일되므로 스칼라 개발자는 모든 Java API를 활용할 수 있다. API 사용은 관련된 프로그래밍 언어의 유형에 따라 달라질 수 있다. 루아(Lua)와 같은 절차적 언어용 API는 기본적으로 코드 실행, 데이터 조작 또는 오류 처리를 위한 기본 루틴으로 구성될 수 있지만 자바와 같은 객체 지향 언어 용 API는 클래스 및 클래스 메소드의 스펙을 제공한다.
언어 바인딩도 API이다. 한 언어의 기능을 다른 언어로 구현된 인터페이스에 매핑하면 언어 바인딩을 통해 한 언어로 작성된 라이브러리 나 서비스를 다른 언어로 개발할 때 사용할 수 있다. 포트란-to-파이썬 인터페이스 생성기인 SWIG 및 F2PY 와 같은 도구는 이러한 인터페이스를 쉽게 만들 수 있다. API는 또한 소프트웨어 프레임워크와 관련될 수 있다. 프레임워크는 여러 API를 구현하는 여러 라이브러리를 기반으로 할 수 있지만 일반적인 API 사용과 달리 프레임워크에 내장된 동작에 대한 액세스는 콘텐츠를 새로운 클래스로 확장하여 조정됩니다 프레임워크 자체에 연결했다. 더욱이, 제어의 전체 프로그램 흐름은 제어의 역전 또는 유사한 메커니즘에 의해 호출자의 제어 및 프레임워크의 손에서 벗어날 수 있다.
운영체제[편집]
API는 응용 프로그램과 운영체제 사이의 인터페이스를 지정할 수 있다. POSIX는, 예를 들면, 하기 POSIX 준수 운영체제 작성된 응용 프로그램 활성화하고자 공통 API 세트를 지정 컴파일 다른 POSIX 준수 운영체제한다. Linux 및 Berkeley Software Distribution 은 POSIX API를 구현하는 운영 체제의 예이다. Microsoft는 특히 Windows API (Win32) 라이브러리 내에서 이전 버전과 호환되는 API에 대한 강력한 의지를 보였어 므로 이전 응용 프로그램은 "호환성 모드"라는 실행 파일 별 설정을 사용하여 최신 버전의 Windows에서 실행될 수 있다. API는 소스 코드 기반이고 ABI는 이진 기반이라는 점에서 API는 ABI ( Application Binary Interface) 와 다르다. 예를 들어 POSIX는 API를 제공하고 Linux Standard Base는 ABI를 제공한다.
원격 API[편집]
원격 API를 통해 개발자는 프로그래밍 언어 또는 플랫폼에 관계없이 서로 다른 기술이 함께 작동할 수 있도록 특정 통신 표준인 프로토콜을 통해 원격 리소스를 조작할 수 있다. 예를 들어, Java Database Connectivity API를 사용하면 개발자는 동일한 기능 세트로 여러 유형의 데이터베이스를 조회할 수 있으며 자바원격 메소드 호출 API는 자바원격 메소드 프로토콜을 사용하여 원격으로 작동하지만 로컬로 표시되는 함수의 호출을 허용한다. 따라서 원격 API는 객체 지향 프로그래밍에서 객체 추상화를 유지하는 데 유용하다. 프락시 객체에서 로컬로 실행되는 메소드 호출은 원격 프로토콜을 사용하여 원격 객체에서 해당 메소드를 호출하고 결과를 로컬로 반환 값으로 사용한다. 프락시 개체를 수정하면 원격 개체도 해당 수정된다.
웹 API[편집]
웹 API는 기능 제공자를 지정하고 API 사용자의 서비스 경로 또는 URL을 공개하기 위한 SLA(Service Level Agreement)인 자산을 사용하는 엔터프라이즈와 애플리케이션 간에 상호 작용이 발생하도록 정의된 인터페이스이다. API 접근 방식은 여러 유형의 소비자에게 서비스를 제공하는 다른 응용 프로그램에 일련의 서비스에 대한 프로그램 인터페이스를 제공하는 것을 중심으로 하는 아키텍처 접근 방식이다. 웹 개발의 맥락에서 사용될 때 API는 일반적으로 HTTP ( Hypertext Transfer Protocol) 요청 메시지 와 같은 일련의 사양으로 정의되며, 일반적으로 XML (Extensible Markup Language)로 응답 메시지 구조의 정의와 함께 정의됩니다. ) 또는 JavaScript 객체 표기법(JSON) 형식이다. 예를 들어, 전자상거래 중심의 웹 사이트에 추가하여 운송 서비스 주문을 용이하게 하고 사이트 개발자가 운송 업체의 요금 표를 웹 데이터베이스에 입력하지 않고도 현재 운송비를 자동으로 포함할 수 있는 운송 회사 API를 예로 들 수 있다.
웹 API는 역사적으로 사실상 웹서비스와 동의어였지만 최근 트렌드(웹 2.0)는 SOAP(Simple Object Access Protocol) 기반 웹서비스 및 SOA(Service-Oriented Architecture)에서 REST(Representational Stateal State Transfer) 스타일 웹 자원 및 ROA(Resource-Oriented Architecture)로 이동하고 있다. 이 추세의 일부는 웹 기반 온톨로지 엔지니어링 기술을 장려하는 개념인 RDF(Resource Description Framework)를 향한 시맨틱웹 이동과 관련이 있다. 웹 API를 사용하면 여러 API를 매시업이라고 하는 새로운 응용 프로그램으로 결합할 수 있다. 소셜 미디어 공간에서 웹 API는 웹 커뮤니티가 커뮤니티와 애플리케이션 간에 콘텐츠 및 데이터 공유를 용이하게 한다. 이러한 방식으로 한 곳에서 동적으로 생성된 콘텐츠를 웹의 여러 위치에 게시하고 업데이트할 수 있다. 예를 들어, 트위터의 REST API는 개발자가 핵심 트위터 데이터에 액세스할 수 있다.[4]
전망[편집]
- 통신·방송·인터넷이 하나의 통합된 전달망을 기반으로 이들간 상호 융합된 서비스들을 제공할 수 있는 광대역 통합망으로 발전할 것이다. [5]
- 금융감독원 기업공시국은 다트(DART)의 오픈 API 정보제공 범위를 현재 기업개황 및 공시 목록에서 세부 공시 내용까지 확대해 21종을 추가 제공해서 공시 이용자가 DART 홈페이지에 방문하지 않아도 원하는 공시서류 원본 파일을 다운로드할 수 있고, 사업보고서 및 분·반기보고서 상에서 공시 이용자들이 관심을 가질 정보를 활용할 수 있게 될 전망이다.[6]
각주[편집]
참고자료[편집]
- 고안해 내는 재능, 〈Open API (Application Program Interface)〉, 《ZUM》, 2007-09-05
- 한수연 기자, 〈공시 보기 편해진다…DART, 오픈API 제공 확대〉, 《아이뉴스 24》, 2009-06-11
- 〈API〉, 《위키피디아》
같이 보기[편집]
