API

NASA가 개발한 웹 API 문서 스크린샷

API(application programming interface 애플리케이션 프로그래밍 인터페이스[*]분류:영어 표기를 포함한 문서#API, 응용 프로그램 프로그래밍 인터페이스)는 컴퓨터나 컴퓨터 프로그램 사이의 연결이다. 일종의 소프트웨어 인터페이스이며 다른 종류의 소프트웨어에 서비스를 제공한다.[1] 이러한 연결 또는 인터페이스를 빌드하거나 사용하는 방법을 기술하는 문서 표준을 API 규격(사양)이라고 한다. 이 표준을 충족하는 컴퓨터 시스템은 API가 구현(implement)되었다거나 노출(expose)되었다고 말한다. API라는 용어는 사양이나 구현체를 의미할 수 있다.

컴퓨터와 인간을 연결시키는 사용자 인터페이스와 반대로, API는 컴퓨터나 소프트웨어를 서로 연결한다. 직접 사람(최종 사용자)에 의해 사용되도록 고안된 것이 아니며, 대신 소프트웨어에 이를 통합하고자 하는 컴퓨터 프로그래머가 사용하도록 고안되었다. API는 각기 다른 부분으로 구성되기도 하며 프로그래머가 사용할 수 있는 도구나 서비스의 역할을 한다. 이러한 부분들 중 하나를 사용하는 프로그램이나 프로그래머는 API의 해당 부분을 호출(call)한다고 말한다. API를 구성하는 호출들은 서브루틴, 메소드(method), 요청, 통신 엔드포인트라고도 부른다. API 규격은 이 호출들을 정의하며, 다시 말해 이들을 어떻게 사용하거나 구현하는지를 설명한다.

API의 한 가지 목적은 시스템이 동작하는 방식에 관한 내부의 세세한 부분을 숨기는 것으로, 내부의 세세한 부분이 나중에 변경되더라도 프로그래머가 유용하게 사용할 수 있고 일정하게 관리할 수 있는 부분들만 노출시킨다. API는 특정 시스템용으로 커스텀하게 빌드될 수도 있고, 아니면 수많은 시스템 간 상호운용성을 허용하는, 공유가 되는 표준일 수도 있다.

API라는 용어는 웹 API를 의미하기도 하며,[2] 이는 인터넷에 의해 병합된 컴퓨터들 간 통신을 허용한다. 프로그래밍 언어, 소프트웨어 라이브러리, 컴퓨터 운영 체제, 컴퓨터 하드웨어를 위한 API도 존재한다. API는 1940년대에 기원하였으나 이 용어는 1960년대, 70년대 들어서야 모습을 드러냈다.

목적

API는 외부의 상호 작용에 소프트웨어 시스템을 개방한다. 두 소프트웨어 시스템이 경계를 넘어 — 인터페이스 — 상호 합의된 신호를 사용하여 통신할 수 있게 한다.[3] 즉, API는 소프트웨어 엔터티를 서로 연결한다. 사용자 인터페이스와 달리 API는 일반적으로 사용자에게 보이지 않는다. 이는 기계 간 통신에 사용되는 소프트웨어 시스템의 "내부" 부분이다.[4]

잘 설계된 API는 소프트웨어 또는 소프트웨어 개발자가 필요로 하는 객체나 작업만 노출한다. 쓸모없는 세부 사항은 숨긴다. 이러한 추상화는 프로그래밍을 단순화한다.[5]

비유적으로 API는 서로 맞물리는 블록처럼 소프트웨어를 연결한다.

API를 사용하여 소프트웨어를 구축하는 것은 레고 블록과 같은 조립 블록 장난감을 사용하는 것에 비유된다. 소프트웨어 서비스 또는 소프트웨어 라이브러리는 블록과 유사하며, API를 통해 서로 연결되어 새로운 소프트웨어 제품을 구성할 수 있다.[6] 연결하는 과정을 통합이라고 한다.[3]

예를 들어, API를 제공하는 기상 센서를 생각해보자. 특정 메시지가 센서로 전송되면, 센서는 현재 기상 조건을 감지하고 기상 보고서로 응답한다. 센서를 활성화하는 메시지는 API 호출이며, 기상 보고서는 API 응답이다.[7] 날씨 예보 앱은 여러 기상 센서 API와 통합하여 지리적 영역 전반의 날씨 데이터를 수집할 수 있다.

API는 종종 계약에 비유된다. 이는 API를 제공하는 서비스 제공자와 이를 의존하는 소프트웨어 개발자 간의 합의를 나타낸다. API가 안정적으로 유지되거나 예측 가능한 방식으로만 변경되면 개발자의 API에 대한 신뢰가 증가한다. 이는 API 사용을 증가시킬 수 있다.[8]

용어의 역사

1978년 응용 프로그램뿐만 아니라 일반적인 프로그래밍 인터페이스로 API 개념을 확장할 것을 제안한 다이어그램[9]

API라는 용어는 처음에는 응용 프로그램이라고 불리는 최종 사용자 지향 프로그램만을 위한 인터페이스를 설명했다. 이러한 기원은 여전히 "응용 프로그래밍 인터페이스"라는 이름에 반영되어 있다. 오늘날 이 용어는 유틸리티 소프트웨어 및 심지어 하드웨어 인터페이스까지 포함하여 더 넓은 의미로 사용된다.[10]

API의 개념은 용어 자체보다 훨씬 오래되었다. 영국의 컴퓨터 과학자 모리스 윌크스와 데이비드 휠러는 초기 컴퓨터인 에드삭을 위한 모듈식 소프트웨어 라이브러리를 1940년대에 개발했다. 이 라이브러리의 서브루틴은 천공 테이프에 저장되었고 파일 캐비닛에 정리되어 있었다. 이 캐비닛에는 윌크스와 휠러가 각 서브루틴과 그것을 프로그램에 통합하는 방법에 대한 "라이브러리 카탈로그"라고 부른 노트도 들어 있었다. 오늘날 이러한 카탈로그는 프로그래머에게 필요한 각 서브루틴을 사용하는(또는 "호출하는") 방법을 지시하기 때문에 API(또는 API 사양 또는 API 문서)라고 불릴 것이다.[10]

윌크스와 휠러의 책 The Preparation of Programs for an Electronic Digital Computer는 최초로 출판된 API 사양을 담고 있다. 조슈아 블로치는 윌크스와 휠러가 API를 "잠재적으로 발명"했다고 평가하는데, 이는 API가 발명되기보다는 발견되는 개념에 가깝기 때문이다.[10]

API라는 용어를 만든 사람들은 유니박 1108에서 소프트웨어를 구현했지만, 그들의 API 목표는 하드웨어 독립적인 프로그램을 가능하게 하는 것이었다.[11]

"응용 프로그램 인터페이스"(-ing 접미사 없음)라는 용어는 1968년 AFIPS 컨퍼런스에서 발표된 "원격 컴퓨터 그래픽스를 위한 데이터 구조 및 기술"이라는 논문에서 처음 기록되었다.[12][10] 이 논문의 저자들은 이 용어를 응용 프로그램 (이 경우 그래픽 프로그램)과 컴퓨터 시스템의 나머지 부분 간의 상호 작용을 설명하는 데 사용한다. 일관된 응용 프로그램 인터페이스(포트란 서브루틴 호출로 구성)는 프로그래머가 그래픽 디스플레이 장치의 특이점을 다루는 부담을 덜어주고, 컴퓨터나 디스플레이가 교체될 경우 하드웨어 독립성을 제공하기 위한 것이었다.[11]

이 용어는 1974년 C. J. 데이트[13]가 "관계형 및 네트워크 접근 방식: 응용 프로그래밍 인터페이스 비교"라는 논문에서 데이터베이스 분야에 도입했다.[14] API는 ANSI/SPARC 프레임워크의 일부가 되었다. 이 프레임워크는 응용 프로그래밍 인터페이스를 쿼리 인터페이스와 같은 다른 인터페이스와 별도로 취급했다. 1970년대의 데이터베이스 전문가들은 이러한 다른 인터페이스를 결합할 수 있다고 관찰했다. 충분히 풍부한 응용 프로그램 인터페이스는 다른 인터페이스도 지원할 수 있었다.[9]

이러한 관찰은 응용 프로그래밍뿐만 아니라 모든 유형의 프로그래밍을 지원하는 API로 이어졌다. 1990년까지 기술자 칼 말라무드는 API를 "특정 작업을 수행하기 위해 프로그래머가 사용할 수 있는 서비스 집합"으로 간단히 정의했다.[15]

미국 항공 우주국이 작성한 웹 API 문서의 스크린샷

API의 개념은 원격 프로시저 호출과 웹 API의 등장으로 다시 확장되었다. 1970년대와 80년대에 컴퓨터 네트워크가 보편화되면서 프로그래머들은 로컬 컴퓨터뿐만 아니라 다른 곳에 위치한 컴퓨터의 라이브러리도 호출하고 싶어했다. 이러한 원격 프로시저 호출은 특히 자바 언어에 의해 잘 지원되었다. 1990년대에는 인터넷의 확산과 함께 CORBA, COM, DCOM과 같은 표준들이 API 서비스를 노출하는 가장 일반적인 방법이 되기 위해 경쟁했다.[16]

로이 필딩의 2000년 UC 어바인에서의 "아키텍처 스타일 및 네트워크 기반 소프트웨어 아키텍처 설계" 논문은 표현 상태 전송 (REST)을 설명하고 전통적인 "라이브러리 기반" API와 대조되는 "네트워크 기반 응용 프로그래밍 인터페이스"의 개념을 제시했다.[17] XML 및 JSON 웹 API는 2000년부터 2021년까지 광범위하게 상업적으로 채택되었다. 이제 웹 API는 API라는 용어의 가장 일반적인 의미이다.[2]

2001년 팀 버너스리가 제안한 시맨틱 웹에는 API를 소프트웨어 동작 인터페이스가 아닌 개방적이고 분산된 데이터 인터페이스로 재정의하는 "시맨틱 API"가 포함되었다.[18] 사유 인터페이스와 에이전트가 개방형보다 더 널리 퍼졌지만, 데이터 인터페이스로서의 API 개념은 확고히 자리 잡았다. 웹 API는 온라인에서 모든 종류의 데이터를 교환하는 데 널리 사용되므로, API는 인터넷 통신의 많은 부분을 설명하는 광범위한 용어가 되었다.[16] 이러한 방식으로 사용될 때, API라는 용어는 통신 프로토콜이라는 용어와 의미가 중복된다.

종류

라이브러리 및 프레임워크

소프트웨어 라이브러리의 인터페이스는 한 가지 유형의 API이다. API는 "예상되는 동작"(사양)을 설명하고 규정하며, 라이브러리는 이러한 규칙 집합의 "실제 구현"이다.

단일 API는 동일한 프로그래밍 인터페이스를 공유하는 여러 라이브러리 형태로 여러 구현(또는 추상적이므로 없음)을 가질 수 있다.

API와 그 구현의 분리는 한 언어로 작성된 프로그램이 다른 언어로 작성된 라이브러리를 사용할 수 있게 한다. 예를 들어, 스칼라와 자바는 호환되는 바이트코드로 컴파일되므로, 스칼라 개발자는 모든 자바 API를 활용할 수 있다.[19]

API 사용은 관련 프로그래밍 언어의 유형에 따라 달라질 수 있다. 절차적 언어(예: 루아)의 API는 주로 코드 실행, 데이터 조작 또는 오류 처리를 위한 기본 루틴으로 구성될 수 있는 반면, 객체 지향 언어(예: 자바)의 API는 클래스 및 클래스 메서드의 사양을 제공한다.[20][21] 하이럼의 법칙은 "API 사용자가 충분히 많으면, 계약에서 무엇을 약속하든 상관없이 시스템의 모든 관찰 가능한 동작은 누군가에게 의존될 것이다."라고 명시한다.[22] 한편, 여러 연구에 따르면 API를 사용하는 대부분의 응용 프로그램은 API의 작은 부분만 사용하는 경향이 있다.[23]

언어 바인딩 또한 API이다. 한 언어의 기능과 능력을 다른 언어로 구현된 인터페이스에 매핑함으로써, 언어 바인딩은 한 언어로 작성된 라이브러리 또는 서비스를 다른 언어로 개발할 때 사용할 수 있게 한다.[24] SWIG 및 포트란-to-파이썬 인터페이스 생성기인 F2PY와 같은 도구는 이러한 인터페이스의 생성을 용이하게 한다.[25]

API는 소프트웨어 프레임워크와 관련될 수도 있다. 프레임워크는 여러 API를 구현하는 여러 라이브러리를 기반으로 할 수 있지만, API의 일반적인 사용과 달리 프레임워크에 내장된 동작에 대한 접근은 새로운 클래스를 프레임워크 자체에 연결하여 내용을 확장함으로써 중재된다.

또한, 전체 프로그램 제어 흐름은 호출자의 제어 범위를 벗어나 제어 반전 또는 유사한 메커니즘에 의해 프레임워크의 제어 하에 있을 수 있다.[26][27]

운영체제

API는 응용 프로그램과 운영체제 간의 인터페이스를 지정할 수 있다.[28] 예를 들어, POSIX는 POSIX 호환 운영체제를 위해 작성된 응용 프로그램이 다른 POSIX 호환 운영체제를 위해 컴파일될 수 있도록 하는 공통 API 집합을 지정한다.

리눅스와 BSD는 POSIX API를 구현하는 운영체제의 예시이다.[29]

마이크로소프트는 특히 윈도우 API (Win32) 라이브러리 내에서 하위 호환 API에 대한 강력한 의지를 보여주어, 오래된 응용 프로그램이 "호환성 모드"라는 실행 파일별 설정을 사용하여 최신 버전의 윈도우에서 실행될 수 있도록 했다.[30] 마이크로소프트 개발자들이 회사의 운영체제 내부 API에 접근할 수 있는 것이 얼마나 이점인지는 불분명하다. 1987년 Technologic Computer Letter의 리처드 A. 샤퍼는 이 상황을 "마이크로소프트가 모든 야구 방망이와 야구장을 소유하고 있다"고 말하며 야구 경기에 비유했지만,[31] 애쉬턴-테이트의 에드 에스버는 그 해 인터뷰에서 빌 게이츠가 자신의 개발자들이 때때로 초기 API를 기반으로 소프트웨어를 다시 작성해야 했다고 말했다고 밝혔다. 게이츠는 인터뷰에서 마이크로소프트의 애플 매킨토시 응용 프로그램이 MS-DOS용보다 더 성공적이었다고 언급했는데, 이는 회사가 맥 OS에도 자원을 투입할 필요가 없었기 때문이라고 했다.[32]

API는 응용 프로그램 이진 인터페이스 (ABI)와 다르다. API는 소스 코드 기반인 반면 ABI는 이진 기반이다. 예를 들어, POSIX는 API를 제공하지만 리눅스 기본 규격은 ABI를 제공한다.[33][34]

원격 API

원격 API는 개발자가 프로토콜(서로 다른 기술이 언어 또는 플랫폼에 관계없이 함께 작동할 수 있도록 하는 특정 통신 표준)을 통해 원격 자원을 조작할 수 있게 한다. 예를 들어, 자바 데이터베이스 연결 API를 통해 개발자는 동일한 함수 집합으로 다양한 유형의 데이터베이스를 쿼리할 수 있으며, 자바 원격 함수 호출 API는 자바 원격 메서드 프로토콜을 사용하여 원격으로 작동하지만 개발자에게는 로컬로 보이는 함수의 호출을 허용한다.[35][36]

따라서 원격 API는 객체 지향 프로그래밍에서 객체 추상화를 유지하는 데 유용하다. 프록시 객체에서 로컬로 실행되는 메서드 호출은 원격 프로토콜을 사용하여 원격 객체에서 해당 메서드를 호출하고, 반환 값으로 로컬에서 사용될 결과를 획득한다.

프록시 객체의 수정은 또한 원격 객체의 해당 수정으로 이어진다.[37]

웹 API

웹 API는 기업과 자산을 사용하는 응용 프로그램 간의 상호 작용이 일어나는 정의된 인터페이스이며, 이는 또한 기능 제공자를 지정하고 API 사용자를 위한 서비스 경로 또는 URL을 노출하는 서비스 수준 협약 (SLA)이기도 하다. API 접근 방식은 다양한 유형의 소비자에게 서비스를 제공하는 다양한 응용 프로그램에 일련의 서비스에 대한 프로그램 인터페이스를 제공하는 것을 중심으로 하는 아키텍처 접근 방식이다.[38]

웹 개발의 맥락에서 사용될 때, API는 일반적으로 하이퍼텍스트 전송 프로토콜 (HTTP) 요청 메시지와 응답 메시지의 구조 정의(일반적으로 확장 가능 마크업 언어(XML) 또는 자바스크립트 객체 표기법(JSON) 형식)와 같은 일련의 사양으로 정의된다. 예를 들어, 전자 상거래 중심 웹사이트에 추가할 수 있는 배송 회사 API가 있을 수 있는데, 이는 사이트 개발자가 운송업체의 요금표를 웹 데이터베이스에 입력할 필요 없이 배송 서비스 주문을 용이하게 하고 현재 운송 요금을 자동으로 포함할 수 있게 한다. 역사적으로 "웹 API"는 사실상 웹 서비스와 동의어였지만, 최근 추세(소위 웹 2.0)는 SOAP 기반 웹 서비스 및 서비스 지향 아키텍처 (SOA)에서 벗어나 보다 직접적인 표현 상태 전송 (REST) 스타일의 웹 리소스 및 자원 지향 아키텍처 (ROA)로 이동하고 있다.[39] 이러한 추세의 일부는 웹 기반 온톨로지 공학 기술을 촉진하는 개념인 자원 기술 프레임워크 (RDF)를 향한 시맨틱 웹 운동과 관련이 있다. 웹 API는 여러 API를 매시업으로 알려진 새로운 응용 프로그램으로 결합할 수 있게 한다.[40] 소셜 미디어 공간에서 웹 API는 웹 커뮤니티가 커뮤니티와 응용 프로그램 간에 콘텐츠와 데이터를 쉽게 공유할 수 있도록 했다. 이러한 방식으로 한 곳에서 동적으로 생성된 콘텐츠를 웹의 여러 위치에 게시하고 업데이트할 수 있다.[41] 예를 들어, 트위터의 REST API는 개발자가 핵심 트위터 데이터에 접근할 수 있게 하며, 검색 API는 개발자가 트위터 검색 및 트렌드 데이터와 상호 작용할 수 있는 메서드를 제공한다.[42]

설계

API의 설계는 사용에 상당한 영향을 미친다.[5] 정보 은닉의 원칙은 프로그래밍 인터페이스의 역할을 모듈의 구현 세부 사항을 숨김으로써 모듈 프로그래밍을 가능하게 하는 것으로 설명하여, 모듈 사용자가 모듈 내부의 복잡성을 이해할 필요가 없도록 한다.[43] 따라서 API의 설계는 사용자가 예상하는 도구만을 제공하려고 한다.[5] 프로그래밍 인터페이스의 설계는 복잡한 소프트웨어의 조직인 소프트웨어 구조의 중요한 부분을 나타낸다.[44]

출시 정책

API는 기술 회사들이 통합하는 가장 일반적인 방법 중 하나이다. API를 제공하고 사용하는 기업들은 비즈니스 생태계의 구성원으로 간주된다.[45]

API를 출시하는 주요 정책은 다음과 같다:[46]

  • 비공개: API는 내부 회사 전용이다.
  • 파트너: 특정 비즈니스 파트너만 API를 사용할 수 있다. 예를 들어, 우버 및 리프트와 같은 승차 공유 회사는 승인된 타사 개발자가 앱 내에서 직접 차량 호출을 주문할 수 있도록 허용한다. 이를 통해 회사는 API에 접근할 수 있는 앱을 선별하여 품질 관리를 행사할 수 있으며, 추가적인 수익원을 제공받는다.[47]
  • 공개: API는 일반 대중이 사용할 수 있다. 예를 들어, 마이크로소프트는 윈도우 API를 공개하고, 애플은 코코아 API를 출시하여 소프트웨어가 자사의 플랫폼용으로 작성될 수 있도록 한다. 모든 공개 API가 모든 사람에게 일반적으로 접근 가능한 것은 아니다. 예를 들어, 클라우드플레어나 복실리티와 같은 인터넷 서비스 제공업체는 RESTful API를 사용하여 고객과 리셀러가 인프라 정보, DDoS 통계, 네트워크 성능 또는 대시보드 제어에 접근할 수 있도록 한다.[48] 이러한 API에 대한 접근은 "API 토큰" 또는 고객 상태 검증을 통해 부여된다.[49]

공개 API의 영향

API가 공개될 때 중요한 요소는 "인터페이스 안정성"이다. API 변경, 예를 들어 함수 호출에 새 매개변수를 추가하는 것은 해당 API에 의존하는 클라이언트와의 호환성을 깨뜨릴 수 있다.[50]

공개된 API의 일부가 변경될 수 있고 따라서 안정적이지 않다면, 해당 API의 그러한 부분은 "불안정"으로 명시적으로 문서화되어야 한다. 예를 들어, 구글 구아바 라이브러리에서 불안정하며 곧 변경될 수 있다고 간주되는 부분은 자바 애너테이션 @Beta로 표시된다.[51]

공개 API는 때때로 자체의 일부를 더 이상 사용되지 않거나 폐기된 것으로 선언할 수 있다. 이는 일반적으로 API의 해당 부분이 제거되거나 하위 호환되지 않는 방식으로 수정될 후보로 간주되어야 함을 의미한다. 따라서 이러한 변경 사항은 개발자가 미래에 제거되거나 지원되지 않을 API의 일부에서 벗어날 수 있도록 한다.[52]

클라이언트 코드는 API 설계자가 의도하지 않은 혁신적이거나 기회주의적인 사용법을 포함할 수 있다. 즉, 상당한 사용자 기반을 가진 라이브러리의 경우, 요소가 공개 API의 일부가 되면 다양한 방식으로 사용될 수 있다.[53] 2020년 2월 19일, 아카마이는 연간 "인터넷 현황" 보고서를 발표하며, 전 세계 금융 서비스의 공개 API 플랫폼을 표적으로 하는 사이버 범죄자들의 증가 추세를 보여주었다. 2017년 12월부터 2019년 11월까지 아카마이는 854억 2천만 건의 자격 증명 침해 공격을 목격했다. 이 중 약 20%인 165억 5천만 건이 API 엔드포인트로 정의된 호스트 이름을 대상으로 했다. 이 중 4억 7350만 건은 금융 서비스 부문 조직을 표적으로 했다.[54]

문서화

API 문서는 API가 제공하는 서비스와 이러한 서비스를 사용하는 방법을 설명하며, 클라이언트가 실제 목적으로 알아야 할 모든 것을 다루는 것을 목표로 한다.

문서는 API를 사용하는 응용 프로그램의 개발 및 유지 보수에 매우 중요하다.[55] API 문서는 전통적으로 문서 파일에서 찾을 수 있지만, 블로그, 포럼, Q&A 웹사이트와 같은 소셜 미디어에서도 찾을 수 있다.[56]

전통적인 문서 파일은 종종 Javadoc 또는 Pydoc과 같이 일관된 모양과 구조를 가진 문서 시스템을 통해 제공된다. 그러나 문서에 포함되는 콘텐츠 유형은 API마다 다르다.[57]

명확성을 위해 API 문서는 API의 클래스 및 메서드에 대한 설명뿐만 아니라 "일반적인 사용 시나리오, 코드 스니펫, 설계 근거, 성능 논의 및 계약"을 포함할 수 있지만, API 서비스 자체의 구현 세부 사항은 일반적으로 생략된다. 이는 설명서, 튜토리얼, 참조서 등 다양한 형태로 제공될 수 있다. 또한 가이드 및 기능 등 다양한 정보 유형을 포함한다.

API 사용 방법에 대한 제한 및 제약 조건도 문서에서 다룬다. 예를 들어, API 함수의 문서는 매개변수가 null일 수 없고, 함수 자체가 스레드 안전하지 않다는 점을 언급할 수 있다.[58] API 문서는 포괄적인 경향이 있으므로, 작성자는 문서를 최신 상태로 유지하고 사용자는 주의 깊게 읽어야 하는 어려움이 있어 잠재적으로 버그가 발생할 수 있다.[50]

API 문서는 자바 애너테이션과 같은 메타데이터 정보로 풍부해질 수 있다. 이 메타데이터는 컴파일러, 도구 및 런타임 환경에서 사용자 정의 동작 또는 사용자 정의 처리를 구현하는 데 사용될 수 있다.[59]

API 문서를 데이터 기반 방식으로 생성하는 것이 가능하다. 주어진 API를 사용하는 많은 프로그램을 관찰함으로써, 일반적인 사용법은 물론 필요한 계약 및 지시사항을 추론할 수 있다.[60] 그런 다음, 템플릿을 사용하여 추출된 데이터로부터 자연어를 생성할 수 있다.

API 저작권 보호에 대한 분쟁

2010년, 오라클 코퍼레이션은 안드로이드 운영 체제에 자바의 새로운 구현을 배포한 것에 대해 구글을 고소했다.[61] 구글은 자바 API를 복제할 어떤 허가도 얻지 않았지만, 유사한 OpenJDK 프로젝트에는 허가가 주어졌다. 판사 윌리엄 알섭은 오라클 대 구글 사건에서 API는 미국에서 저작권이 될 수 없으며, 오라클의 승리는 "기능적 기호 집합"에 대한 저작권 보호를 광범위하게 확장하고 단순한 소프트웨어 명령에 대한 저작권을 허용했을 것이라고 판결했다.

오라클의 주장을 받아들이는 것은 누군가가 명령 시스템을 수행하기 위한 코드의 한 버전에 저작권을 부여하고, 그로 인해 다른 모든 사람이 동일한 명령의 전부 또는 일부를 수행하기 위한 다른 버전을 작성하는 것을 막는 것을 허용하는 것이다.[62][63]

알섭의 판결은 2014년 미국 연방 순회 항소법원에 대한 항소심에서 뒤집혔지만, API의 그러한 사용이 공정 이용에 해당하는지에 대한 문제는 미해결 상태로 남았다.[64][65]

2016년, 2주간의 재판 끝에 배심원단은 구글의 자바 API 재구현이 공정 이용에 해당한다고 판결했지만, 오라클은 이 결정에 항소하겠다고 맹세했다.[66] 오라클은 항소심에서 승리했고, 연방 순회 항소법원은 구글의 API 사용이 공정 이용에 해당하지 않는다고 판결했다.[67] 2019년, 구글은 저작권 침해 및 공정 이용 판결 모두에 대해 미국 연방 대법원에 상고했고, 대법원은 재심을 허가했다.[68] 코로나19 범유행으로 인해 이 사건의 구두 변론은 2020년 10월로 연기되었다.[69]

사건은 대법원에서 구글의 손을 들어주었다.[70]

예시

같이 보기

각주

  1. ↑ Reddy, Martin (2011). 《API Design for C++》. Elsevier Science. 1쪽. ISBN 9780123850041.
  2. 1 2 Lane, Kin (2019년 10월 10일). “Intro to APIs: History of APIs”. 《Postman》. 2020년 9월 18일에 확인함. When you hear the acronym “API” or its expanded version “Application Programming Interface,” it is almost always in reference to our modern approach, in that we use HTTP to provide access to machine readable data in a JSON or XML format, often simply referred to as “web APIs.” APIs have been around almost as long as computing, but modern web APIs began taking shape in the early 2000s.
  3. 1 2 Pedro, Bruno (2024). 《Building an API Product: Design, Implement, Release, and Maintain API Products that Meet User Needs》. Packt Publishing. 4쪽. ISBN 9781837638536.
  4. ↑ Biehl, Matthias (2016). 《RESTful API Design》. API-University Press. 10쪽. ISBN 9781514735169.
  5. 1 2 3 Clarke, Steven (2004). “Measuring API Usability”. 《Dr. Dobb's》. 2016년 7월 29일에 확인함.
  6. ↑ Jin, Brenda; Sahni, Saurabh; Shevat, Amir (2018). 〈Preface〉. 《Designing Web APIs: Building APIs That Developers Love》. O'Reilly Media. ISBN 9781492026877.
  7. ↑ Geewax, JJ (2021). 《API Design Patterns》. Manning. 6쪽. ISBN 9781638350330.
  8. ↑ Jacobson, Daniel; Brail, Greg; Woods, Dan (2011). 《APIs: A Strategy Guide》. O'Reilly Media. 4쪽. ISBN 9781449321642.
  9. 1 2 Database architectures – a feasibility workshop (보고서). Washington, DC: U.S. Department of Commerce, National Bureau of Standards. April 1981. 45–47쪽. hdl:2027/mdp.39015077587742?urlappend=%3Bseq=53. LCCN 81600004. NBS special publication 500-76. 2020년 9월 18일에 확인함.
  10. 1 2 3 4 Bloch, Joshua (2018년 8월 8일). 《A Brief, Opinionated History of the API》 (연설). QCon. San Francisco: InfoQ. 2020년 9월 18일에 확인함.
  11. 1 2 Cotton, Ira W.; Greatorex, Frank S. (December 1968). 〈Data structures and techniques for remote computer graphics〉. 《AFIPS '68: Proceedings of the December 9–11, 1968, Fall Joint Computer Conference》. AFIPS 1968 Fall Joint Computer Conference. San Francisco, California: Association for Computing Machinery. 533–544쪽. doi:10.1145/1476589.1476661. ISBN 978-1450378994. OCLC 1175621908.
  12. ↑ 〈application program interface〉. 《옥스퍼드 영어사전》 온라인판. 옥스퍼드 대학교 출판부. (구독 또는 참여 기관 회원가입 필요)
  13. ↑ Date, C. J. (2019). 《E. F. Codd and Relational Theory: A Detailed Review and Analysis of Codd's Major Database Writings》. Lulu.com. 135쪽. ISBN 978-1684705276.
  14. ↑ Date, C. J.; Codd, E. F. (January 1975). 〈The relational and network approaches: Comparison of the application programming interfaces〉. Randall Rustin. 《Proceedings of 1974 ACM-SIGMOD Workshop on Data Description, Access and Control》. SIGMOD Workshop 1974. Ann Arbor, Michigan: Association for Computing Machinery. 83–113쪽. doi:10.1145/800297.811532. ISBN 978-1450374187. OCLC 1175623233.
  15. ↑ Carl, Malamud (1990). 《Analyzing Novell Networks》. Van Nostrand Reinhold. 294쪽. ISBN 978-0442003647.
  16. 1 2 Jin, Brenda; Sahni, Saurabh; Shevat, Amir (2018). 《Designing Web APIs》. O'Reilly Media. ISBN 9781492026877.
  17. ↑ Fielding, Roy (2000). 《Architectural Styles and the Design of Network-based Software Architectures》 (PhD). 2020년 9월 18일에 확인함.
  18. ↑ Dotsika, Fefie (August 2010). 《Semantic APIs: Scaling up towards the Semantic Web》. 《International Journal of Information Management》 30. 335–342쪽. doi:10.1016/j.ijinfomgt.2009.12.003.
  19. ↑ Odersky, Martin; Spoon, Lex; Venners, Bill (2008년 12월 10일). “Combining Scala and Java”. 《www.artima.com》. 2016년 7월 29일에 확인함.
  20. ↑ de Figueiredo, Luiz Henrique; Ierusalimschy, Roberto; Filho, Waldemar Celes (1994). 〈The design and implementation of a language for extending applications〉. 《Proceedings of XXI Brazilian Seminar on Software and Hardware》. 273–284쪽. CiteSeerX 10.1.1.47.5194. S2CID 59833827. 2016년 7월 29일에 확인함.
  21. ↑ Sintes, Tony (13 July 2001). “Just what is the Java API anyway?”. 《JavaWorld》. 2020년 7월 18일에 확인함.
  22. ↑ Winters, Titus; Tom Manshreck; Hyrum Wright, 편집. (2020). 《Software engineering at Google: lessons learned from programming over time》. Sebastopol, CA: O'Reilly Media. ISBN 9781492082798. OCLC 1144086840.
  23. ↑ Mastrangelo, Luis; Ponzanelli, Luca; Mocci, Andrea; Lanza, Michele; Hauswirth, Matthias; Nystrom, Nathaniel (2015년 10월 23일). 〈Use at your own risk: the Java unsafe API in the wild〉. 《Proceedings of the 2015 ACM SIGPLAN International Conference on Object-Oriented Programming, Systems, Languages, and Applications》. New York, New York, U.S.: Association for Computing Machinery. 695–710쪽. doi:10.1145/2814270.2814313. ISBN 978-1-4503-3689-5.
  24. ↑ Emery, David. “Standards, APIs, Interfaces and Bindings”. Acm.org. 2015년 1월 16일에 원본 문서에서 보존된 문서. 2016년 8월 8일에 확인함.
  25. ↑ “F2PY.org”. F2PY.org. 2011년 12월 18일에 확인함.
  26. ↑ Fowler, Martin. “Inversion Of Control”.
  27. ↑ Fayad, Mohamed. “Object-Oriented Application Frameworks”.
  28. ↑ Lewine, Donald A. (1991). 《POSIX Programmer's Guide》. O'Reilly & Associates, Inc. 1쪽. ISBN 9780937175736. 2016년 8월 2일에 확인함.
  29. ↑ West, Joel; Dedrick, Jason (2001). 《Open source standardization: the rise of Linux in the network era》 (PDF). 《Knowledge, Technology & Policy》 14. 88–112쪽. doi:10.1007/PL00022278. 2016년 8월 2일에 확인함.
  30. ↑ Microsoft (October 2001). “Support for Windows XP”. Microsoft. 4쪽. 2009년 9월 26일에 원본 문서에서 보존된 문서.
  31. ↑ Barney, Douglas (1987년 11월 2일). “Balancing on the high wire of Microsoft's success”. 《Computerworld》. XXI권 44호. SR15쪽. 2025년 6월 8일에 확인함.
  32. ↑ Gates, Bill; Manzi, Jim; Esber, Ed (1987년 11월 2일). 《The great software debate》. 《Computerworld》 XXI (44). 인터뷰어: Paul Gillin. SR7쪽. 2025년 6월 8일에 확인함.
  33. ↑ “LSB Introduction”. Linux Foundation. 2012년 6월 21일. 2015년 4월 2일에 원본 문서에서 보존된 문서. 2015년 3월 27일에 확인함.
  34. ↑ Stoughton, Nick (April 2005). “Update on Standards” (PDF). USENIX. 2009년 6월 4일에 확인함.
  35. ↑ Bierhoff, Kevin (2009년 4월 23일). 《API Protocol Compliance in Object-Oriented Software》 (PDF). 《CMU Institute for Software Research》. 2016년 7월 29일에 확인함.
  36. ↑ Wilson, M. Jeff (10 November 2000). “Get smart with proxies and RMI”. 《JavaWorld》. 2020년 7월 18일에 확인함.
  37. ↑ Henning, Michi; Vinoski, Steve (1999). 《Advanced CORBA Programming with C++》. 애디슨-웨슬리. ISBN 978-0201379273. 2015년 6월 16일에 확인함.
  38. ↑ “API-fication” (PDF). 《www.hcltech.com》. August 2014.
  39. ↑ Benslimane, Djamal; Schahram Dustdar; Amit Sheth (2008). 《Services Mashups: The New Generation of Web Applications》. 《IEEE Internet Computing》 12 (IEEE). 13–15쪽. doi:10.1109/MIC.2008.110. 2019년 10월 1일에 확인함.
  40. ↑ Niccolai, James (2008년 4월 23일), “So What Is an Enterprise Mashup, Anyway?”, 《PC World》, 2017년 10월 10일에 원본 문서에서 보존된 문서, 2017년 9월 17일에 확인함
  41. ↑ Parr, Ben (2009년 5월 21일). “The Evolution of the Social Media API”. 《Mashable》. 2016년 7월 26일에 확인함.
  42. ↑ “GET trends/place”. 《developer.twitter.com》 (영어). 2020년 4월 30일에 확인함.분류:CS1 - 영어 인용 (en)
  43. ↑ Parnas, D.L. (1972). 《On the Criteria To Be Used in Decomposing Systems into Modules》 (PDF). 《Communications of the ACM》 15. 1053–1058쪽. doi:10.1145/361598.361623. S2CID 53856438.
  44. ↑ Garlan, David; Shaw, Mary (January 1994). 《An Introduction to Software Architecture》 (PDF). 《Advances in Software Engineering and Knowledge Engineering》 1. 2016년 8월 8일에 확인함.
  45. ↑ de Ternay, Guerric (2015년 10월 10일). “Business Ecosystem: Creating an Economic Moat”. 《BoostCompanies》. 2016년 9월 17일에 원본 문서에서 보존된 문서. 2016년 2월 1일에 확인함.
  46. ↑ Boyd, Mark (2014년 2월 21일). “Private, Partner or Public: Which API Strategy Is Best for Business?”. 《ProgrammableWeb》. 2016년 8월 2일에 확인함.
  47. ↑ Weissbrot, Alison (2016년 7월 7일). “Car Service APIs Are Everywhere, But What's In It For Partner Apps?”. 《AdExchanger》.
  48. ↑ “Cloudflare API v4 Documentation”. 《cloudflare》. 2020년 2월 25일. 2020년 2월 27일에 확인함.
  49. ↑ Liew, Zell (2018년 1월 17일). “Car Service APIs Are Everywhere, But What's In It For Partner Apps”. 《Smashing Magazine》. 2020년 2월 27일에 확인함.
  50. 1 2 Shi, Lin; Zhong, Hao; Xie, Tao; Li, Mingshu (2011). 《An Empirical Study on Evolution of API Documentation》. International Conference on Fundamental Approaches to Software Engineering. Lecture Notes in Computer Science. 416–431쪽. doi:10.1007/978-3-642-19811-3_29. ISBN 978-3-642-19810-6. 2016년 7월 22일에 확인함.
  51. ↑ (영어) google/guava: Google Core Libraries for Java - 깃허브
  52. ↑ Oracle. “How and When to Deprecate APIs”. 《Java SE Documentation》. 2016년 8월 2일에 확인함.
  53. ↑ Mendez, Diego; Baudry, Benoit; Monperrus, Martin (2013). 《Empirical evidence of large-scale diversity in API usage of object-oriented software》. 2013 IEEE 13th International Working Conference on Source Code Analysis and Manipulation (SCAM). 43–52쪽. arXiv:1307.4062. doi:10.1109/SCAM.2013.6648183. ISBN 978-1-4673-5739-5. S2CID 6890739.
  54. ↑ Takanashi, Dean (2020년 2월 19일). “Akamai: Cybercriminals are attacking APIs at financial services firms”. 《Venture Beat》. 2020년 2월 27일에 확인함.
  55. ↑ Dekel, Uri; Herbsleb, James D. (May 2009). 《Improving API Documentation Usability with Knowledge Pushing》. 《Institute for Software Research, School of Computer Science》. CiteSeerX 10.1.1.446.4214.
  56. ↑ Parnin, Chris; Treude, Cristoph (May 2011). 〈Measuring API documentation on the web〉. 《Proceedings of the 2nd International Workshop on Web 2.0 for Software Engineering》. 25–30쪽. doi:10.1145/1984701.1984706. ISBN 9781450305952. S2CID 17751901. 2016년 7월 22일에 확인함.
  57. ↑ Maalej, Waleed; Robillard, Martin P. (September 2012). 《Patterns of Knowledge in API Reference Documentation》 (PDF). 《IEEE Transactions on Software Engineering》 39. 1264–1282쪽. doi:10.1109/TSE.2013.12. 2016년 7월 22일에 확인함.
  58. ↑ Monperrus, Martin; Eichberg, Michael; Tekes, Elif; Mezini, Mira (2011년 12월 3일). 《What should developers be aware of? An empirical study on the directives of API documentation》. 《Empirical Software Engineering》 17. 703–737쪽. arXiv:1205.6363. doi:10.1007/s10664-011-9186-4. S2CID 8174618.
  59. ↑ “Annotations”. 썬 마이크로시스템즈. 2011년 9월 25일에 원본 문서에서 보존된 문서. 2011년 9월 30일에 확인함..
  60. ↑ Bruch, Marcel; Mezini, Mira; Monperrus, Martin (2010). 《Mining subclassing directives to improve framework reuse》. 2010 7th IEEE Working Conference on Mining Software Repositories (MSR 2010). 141–150쪽. CiteSeerX 10.1.1.434.15. doi:10.1109/msr.2010.5463347. ISBN 978-1-4244-6802-7. S2CID 1026918.
  61. ↑ “Oracle and the End of Programming As We Know It”. DrDobbs. 2012년 5월 1일. 2012년 5월 9일에 확인함.
  62. ↑ “APIs Can't be Copyrighted Says Judge in Oracle Case”. TGDaily. 2012년 6월 1일. 2012년 12월 6일에 확인함.
  63. ↑ “Oracle America, Inc. vs. Google Inc.” (PDF). Wired. 2012년 5월 31일. 2013년 9월 22일에 확인함.
  64. ↑ “Oracle Am., Inc. v. Google Inc., No. 13-1021, Fed. Cir. 2014”.
  65. ↑ Rosenblatt, Seth (2014년 5월 9일). “Court sides with Oracle over Android in Java patent appeal”. 《CNET》. 2014년 5월 10일에 확인함.
  66. ↑ “Google beats Oracle – Android makes "fair use" of Java APIs”. 《Ars Technica》. 2016년 5월 26일. 2016년 7월 28일에 확인함.
  67. ↑ Decker, Susan (2018년 3월 27일). “Oracle Wins Revival of Billion-Dollar Case Against Google”. 《블룸버그 비즈니스위크》. 2018년 3월 27일에 확인함.
  68. ↑ Lee, Timothy (2019년 1월 25일). “Google asks Supreme Court to overrule disastrous ruling on API copyrights”. 《아르스 테크니카》. 2019년 2월 8일에 확인함.
  69. ↑ vkimber (2020년 9월 28일). “Google LLC v. Oracle America, Inc.”. 《LII / Legal Information Institute》 (영어). 2021년 3월 6일에 확인함.분류:CS1 - 영어 인용 (en)
  70. ↑ “Supreme Court of the United States, No. 18–956, GOOGLE LLC, PETITIONER v. ORACLE AMERICA, INC.” (PDF). 2021년 4월 5일.

외부 링크

  • 위키미디어 공용에 API 관련 미디어 분류가 있습니다.
분류:위키데이터 속성 P227을 사용하는 문서분류:위키데이터 속성 P244를 사용하는 문서분류:위키데이터 속성 P268을 사용하는 문서분류:위키데이터 속성 P373을 사용하는 문서분류:위키데이터 속성 P8189를 사용하는 문서 분류:API#%20 분류:기술 소통
분류:API 분류:CS1 - 영어 인용 (en) 분류:기술 소통 분류:영어 표기를 포함한 문서 분류:위키데이터 속성 P227을 사용하는 문서 분류:위키데이터 속성 P244를 사용하는 문서 분류:위키데이터 속성 P268을 사용하는 문서 분류:위키데이터 속성 P373을 사용하는 문서 분류:위키데이터 속성 P8189를 사용하는 문서