API

API
기타 용도는 API(동음이의)를 참조하십시오.
"Api.php"는 여기로 리디렉션됩니다.Wikipedia API는 Special:ApiHelp.
나사가 작성한 웹 API 문서 스크린샷

API(Application Programming Interface)는 사용자 인터페이스와 대조됩니다.둘 이상의 컴퓨터 프로그램이 서로 소통하는 방식입니다.소프트웨어 인터페이스의 한 종류로, 다른 소프트웨어에 서비스를 제공합니다.[1]이러한 연결이나 인터페이스를 구축하거나 사용하는 방법을 설명하는 문서나 표준을 API 사양이라고 합니다.이 기준을 충족하는 컴퓨터 시스템은 API를 구현하거나 노출한다고 합니다.API라는 용어는 규격 또는 구현을 의미할 수 있습니다.

컴퓨터와 사람을 연결하는 사용자 인터페이스와 달리 응용 프로그램 인터페이스는 컴퓨터나 소프트웨어를 서로 연결합니다.소프트웨어에 통합하는 컴퓨터 프로그래머가 아닌 사용자(최종 사용자)가 직접 사용하도록 의도된 것은 아닙니다.API는 프로그래머가 사용할 수 있는 도구나 서비스 역할을 하는 다양한 부분으로 구성되는 경우가 많습니다.이러한 부분 중 하나를 사용하는 프로그래머 또는 프로그래머가 API의 그 부분을 호출한다고 합니다.API를 구성하는 호출은 서브루틴, 메소드, 요청 또는 엔드포인트라고도 합니다.API 규격은 이러한 호출을 정의합니다. 즉, 호출을 사용하거나 구현하는 방법을 설명합니다.

API의 한 가지 목적은 시스템의 작동 방식에 대한 내부 세부 정보를 숨기고 프로그래머가 유용하다고 생각하는 부분만 노출하며 나중에 내부 세부 정보가 바뀌더라도 일관성을 유지하는 것입니다.API는 특정 시스템 쌍을 위해 맞춤형으로 제작될 수도 있고, 많은 시스템 간의 상호 운용성을 허용하는 공유 표준일 수도 있습니다.

프로그래밍 언어, 소프트웨어 라이브러리, 컴퓨터 운영 체제, 컴퓨터 하드웨어를 위한 API가 있습니다.API는 1940년대에 시작되었지만 이 용어는 1960년대와 1970년대까지 등장하지 않았습니다.API라는 용어의 현대적인 용법은 종종 인터넷에 의해 연결된 컴퓨터들 사이의 통신을 허용하는 [2]웹 API를 말합니다.최근 API의 발전으로 공개 API를 통해 접근하는 느슨하게 결합된 서비스인 마이크로 서비스의 인기가 높아지고 있습니다.[3]

목적

애플리케이션을 구축할 때 API는 기본 구현을 추상화하고 개발자가 필요로 하는 객체나 작업만 노출함으로써 프로그래밍을 단순화합니다.이메일 클라이언트를 위한 그래픽 인터페이스는 사용자에게 새로운 이메일을 가져오고 강조하기 위한 모든 단계를 수행하는 버튼을 제공할 수 있지만,파일 입력/출력을 위한 API는 개발자에게 파일 시스템 작동을 막후에서 이해할 필요 없이 한 위치에서 다른 위치로 파일을 복사하는 기능을 제공할 수 있습니다.[4]

기명이력

응용 프로그램만을 넘어[5] 일반 프로그래밍 인터페이스로 API의 개념을 확장할 것을 제안하는 1978년의 다이어그램

API라는 용어는 처음에는 응용 프로그램으로 알려진 최종 사용자 대면 프로그램만을 위한 인터페이스를 설명했습니다.이 원점은 여전히 "애플리케이션 프로그래밍 인터페이스"라는 이름에 반영되어 있습니다.오늘날 이 용어는 유틸리티 소프트웨어와 심지어 하드웨어 인터페이스까지 포함하여 더 광범위합니다.[6]

1940년대와 1950년대

API의 개념은 용어 자체보다 훨씬 오래되었습니다.영국의 컴퓨터 과학자 모리스 윌크스와 데이비드 휠러는 1940년대에 초기 컴퓨터인 EDSAC을 위해 모듈형 소프트웨어 라이브러리를 제작했습니다.이 라이브러리의 서브루틴은 파일링 캐비닛에 정리된 천공된 종이 테이프에 저장되었습니다.또한 이 캐비닛에는 Wilkes and Wheeler가 각 서브루틴에 대한 메모를 "도서관 카탈로그"라고 부르는 것과 그것을 프로그램에 통합하는 방법이 들어 있었습니다.오늘날 이러한 카탈로그는 프로그래머가 필요로 하는 각 서브루틴을 어떻게 사용(또는 "콜")할 것인지에 대해 프로그래머에게 지시하기 때문에 API(또는 API 사양 또는 API 문서)라고 불립니다.[6]

Wilkes and Wheeler의 1951년 저서인 The Preparation of Programs for an Electronic Digital Computer는 최초로 출판된 API 사양을 포함하고 있습니다.Joshua Bloch는 Wilkes와 Wheeler가 API가 발명된 것이라기 보다는 발견된 개념이기 때문에 API를 "최근에 발명"했다고 생각합니다.[6]

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

1960~70년대

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

이 용어는 1974년 C. J. Date에[9] 의해 The Relational and Network Approaches: Comparison of the Application Programming Interface라는 논문에서 데이터베이스 분야에 소개되었습니다.[10]API는 데이터베이스 관리 시스템을 위한 ANSI/SPARC 프레임워크의 일부가 되었습니다.이 프레임워크는 애플리케이션 프로그래밍 인터페이스를 쿼리 인터페이스와 같은 다른 인터페이스와 별도로 취급했습니다.1970년대의 데이터베이스 전문가들은 이와 같이 서로 다른 인터페이스를 결합할 수 있으며, 충분히 풍부한 애플리케이션 인터페이스가 다른 인터페이스들도 지원할 수 있을 것으로 예상했습니다.[5]

이러한 관찰은 애플리케이션 프로그래밍뿐만 아니라 모든 유형의 프로그래밍을 지원하는 API로 이어졌습니다.

1990년대

1990년까지 API는 단순히 기술자 칼 말라무드에 의해 "프로그래머가 특정 작업을 수행하기 위해 사용할 수 있는 서비스 집합"으로 정의되었습니다.[11]

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

2000년대

Roy Fielding이 2000년 UC Irvine에서 발표한 Architectural Styles and Design of Network-based Software Architecture는 REST(Representational state transfer)의 개요를 설명하고, Fielding이 기존의 "라이브러리 기반" API와 대비되는 "네트워크 기반 응용 프로그램 인터페이스"의 아이디어를 설명했습니다.[13]XML 및 JSON 웹 API는 2000년에 시작하여 2022년 현재까지 광범위한 상업적 채택이 이루어졌습니다.웹 API는 이제 API라는 용어의 가장 일반적인 의미입니다.[2]

2001년 팀 버너스리(Tim Berners-Lee)가 제안한 시맨틱 웹(Semantic Web)에는 API를 소프트웨어 동작 인터페이스가 아닌 개방형 분산 데이터 인터페이스로 재분류하는 "시맨틱 API"가 포함되어 있습니다.[14]독점 인터페이스와 에이전트는 개방형 인터페이스보다 더 널리 보급되었지만, API를 데이터 인터페이스로 생각하는 것이 일반적이었습니다.웹 API는 온라인에서 모든 종류의 데이터를 교환하는 데 널리 사용되기 때문에, API는 인터넷 상의 많은 통신을 설명하는 광범위한 용어가 되었습니다.[12]이와 같이 사용될 경우, API라는 용어는 통신 프로토콜이라는 용어와 의미가 겹칩니다.

사용.

라이브러리 및 프레임워크

소프트웨어 라이브러리에 대한 인터페이스는 API의 한 종류입니다.API는 "예상 동작"(명세)을 설명하고 규정하며 라이브러리는 이 규칙 집합의 "실제 구현"입니다.

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

API를 구현에서 분리하면 한 언어로 작성된 프로그램이 다른 언어로 작성된 라이브러리를 사용할 수 있습니다.예를 들어, Scala와 Java가 호환되는 바이트코드로 컴파일하기 때문에 Scala 개발자는 모든 Java API를 활용할 수 있습니다.[15]

API 사용은 관련된 프로그래밍 언어의 종류에 따라 달라질 수 있습니다.Lua와 같은 절차 언어의 API는 주로 코드를 실행하고 데이터를 조작하거나 오류를 처리하는 기본 루틴으로 구성될 수 있으며 자바와 같은 객체 지향 언어의 API는 클래스와 클래스 방법의 사양을 제공합니다.[16][17]하이럼의 법칙은 "충분한 수의 API 사용자가 있다면 계약에서 무엇을 약속하는지는 중요하지 않습니다. 시스템의 모든 관찰 가능한 행동은 누군가에 의해 좌우됩니다."라고 말합니다.한편, 여러 연구에 따르면 API를 사용하는 대부분의 애플리케이션은 API의 작은 부분을 사용하는 경향이 있습니다.[19]

언어 바인딩도 API입니다.언어 바인딩은 한 언어의 특징과 기능을 다른 언어로 구현된 인터페이스에 매핑하여 한 언어로 작성된 라이브러리 또는 서비스를 다른 언어로 개발할 때 사용할 수 있도록 합니다.[20]

SWIG나 Fortran-to-Python 인터페이스 생성기인 F2PY와 같은 도구들은 그러한 인터페이스의 생성을 용이하게 합니다.[21]

API는 소프트웨어 프레임워크와 관련될 수도 있습니다. 프레임워크는 여러 API를 구현하는 여러 라이브러리를 기반으로 할 수 있지만, API의 일반적인 사용과는 달리 프레임워크 자체에 연결된 새로운 클래스로 콘텐츠를 확장하여 프레임워크에 내장된 동작에 대한 액세스를 매개합니다.

게다가, 전반적인 제어의 프로그램 흐름은 호출자의 통제를 벗어나서, 제어의 반전이나 유사한 메커니즘에 의해 프레임워크의 손에 있을 수 있습니다.[22][23]

운영 체제

API는 응용프로그램과 운영체제 사이의 인터페이스를 지정할 수 있습니다.[24]예를 들어, POSIX는 POSIX 적합 운영 체제를 위해 작성된 애플리케이션이 다른 POSIX 적합 운영 체제를 위해 컴파일될 수 있도록 하는 것을 목표로 하는 일련의 공통 API 사양을 제공합니다.

리눅스와 버클리 소프트웨어 배포판은 POSIX API를 구현하는 운영 체제의 예입니다.[25]

Microsoft는 하위 호환성 API, 특히 Windows API(Win32) 라이브러리에 대한 강력한 의지를 보여주었기 때문에 "호환성 모드"라는 실행 파일별 설정을 사용하여 이전 버전의 응용 프로그램이 최신 버전의 Windows에서 실행될 수 있습니다.[26]

API는 ABI(Application Binary Interface)와는 다른 점이 있습니다.예를 들어, POSIX는 API를 제공하고 Linux Standard Base는 ABI를 제공합니다.[27][28]

원격 API

원격 API를 통해 개발자는 언어나 플랫폼에 관계없이 서로 다른 기술이 함께 작동할 수 있는 통신에 대한 특정 표준인 프로토콜을 통해 원격 리소스를 조작할 수 있습니다.예를 들어, Java Database Connectivity API를 통해 개발자는 동일한 기능 집합을 가진 다양한 유형의 데이터베이스를 쿼리할 수 있으며, Java 원격 메서드 호출 API는 Java Remote Method Protocol을 사용하여 원격으로 작동하지만 개발자에게 로컬로 나타나는 기능을 호출할 수 있습니다.[29][30]

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

프록시 개체도 수정하면 원격 개체도 수정됩니다.[31]

웹 API

주요 기사:웹 API

웹 API는 HTTP(Hypertext Transfer Protocol)를 사용하여 클라이언트 장치(휴대전화, 노트북 등)에서 웹 서버로 액세스하는 서비스입니다.클라이언트 장치는 HTTP 요청 형식으로 요청을 보내고, 응답 메시지를 보통 JSON(JavaScript Object Notation) 또는 XML(Extensible Markup Language) 형식으로 받습니다.개발자는 일반적으로 웹 API를 사용하여 서버에서 특정 데이터 집합을 쿼리합니다.

예를 들어, 배송업체 API를 eCommerce 중심의 웹 사이트에 추가하여 배송 서비스 주문을 용이하게 하고 사이트 개발자가 웹 데이터베이스에 배송업체의 요금표를 입력할 필요 없이 현재 배송 요금을 자동으로 포함할 수 있습니다."웹 API"는 역사적으로 웹 서비스와 사실상 동의어였지만, 최근 추세(이른바 웹 2).0)SOAP(Simple Object Access Protocol) 기반 웹 서비스 및 SOA(Service Oriental Architecture)에서 REST(Responential State Transfer) 스타일의 웹 리소스 및 ROA(Resource Oriental Architecture)[32]로 전환하고 있습니다.이러한 추세의 일부는 웹 기반 온톨로지 엔지니어링 기술을 촉진하기 위한 개념인 RDF(Resource Description Framework)를 향한 시맨틱 웹(Semantic Web) 운동과 관련이 있습니다.웹 API를 사용하면 여러 API를 매쉬업이라고 하는 새로운 응용 프로그램으로 결합할 수 있습니다.[33]

소셜 미디어 공간에서 웹 API는 웹 커뮤니티가 커뮤니티와 애플리케이션 간의 콘텐츠 및 데이터 공유를 용이하게 할 수 있도록 했습니다.이렇게 하면 한 곳에서 동적으로 작성된 내용을 웹의 여러 위치에 게시하고 업데이트할 수 있습니다.[34]예를 들어, 트위터의 REST API는 개발자들이 핵심 트위터 데이터에 접근할 수 있도록 하고 Search API는 개발자들이 트위터 Search 및 트렌드 데이터와 상호 작용할 수 있는 방법을 제공합니다.[35]

설계.

API의 설계는 API의 사용에 상당한 영향을 미칩니다.[4]우선, 프로그래밍 인터페이스의 설계는 소프트웨어 아키텍처의 중요한 부분, 즉 복잡한 소프트웨어의 조직을 나타냅니다.[36]정보 숨김의 원리는 모듈 사용자가 모듈 내부의 복잡성을 이해할 필요가 없도록 모듈의 구현 내용을 숨김으로써 모듈 프로그래밍을 가능하게 하는 프로그래밍 인터페이스의 역할을 설명합니다.[37]이전의 기본 원칙 이외에도 API의 사용성을 측정하기 위한 다른 메트릭에는 기능 효율성, 전반적인 정확성, 초보자의 학습 가능성 등의 속성이 포함될 수 있습니다.[38]API를 설계하는 한 가지 간단하고 일반적으로 채택되는 방법은 닐슨의 휴리스틱 평가 지침을 따르는 것입니다.Factory 메서드 패턴은 재사용 가능한 특성 때문에 API를 설계할 때도 일반적입니다.[39]따라서 API의 설계는 사용자가 기대할 수 있는 도구만을 제공하려고 시도합니다.[4]

동기식 대 비동기식

애플리케이션 프로그래밍 인터페이스는 동기식일 수도 있고 비동기식일 수도 있습니다.동기 API 호출은 호출된 코드가 끝날 때까지 기다리는 동안 호출 사이트가 차단되는 설계 패턴입니다.[40]그러나 비동기 API 호출에서는 호출된 코드가 끝날 때까지 기다리는 동안 호출 사이트가 차단되지 않고 대신 응답이 도착하면 호출 스레드가 알려집니다.

보안.

퍼블릭 페이싱 API를 개발할 때는 API 보안이 매우 중요합니다.일반적인 위협 요소로는 SQL 주입, DoS(서비스 거부 공격), 인증 중단, 중요 데이터 노출 등이 있습니다.[41]보안 관행을 제대로 보장하지 않으면 나쁜 행위자는 보유하지 말아야 할 정보에 액세스하거나 서버를 변경할 수 있는 권한을 얻을 수 있습니다.몇 가지 일반적인 보안 방식으로는 HTTPS를 이용한 적절한 연결 보안, 데이터 주입 공격을 완화하기 위한 컨텐츠 보안, 서비스를 사용하기 위한 API 키 요구 등이 있습니다.[42]많은 공용 API 서비스는 할당된 API 키를 사용해야 하며, 키를 요청과 함께 보내지 않으면 데이터 서비스를 거부합니다.[43]

릴리스 정책

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

API 공개를 위한 주요 정책은 다음과 같습니다.[45]

  • 비공개:API는 사내 전용입니다.
  • 파트너:특정 사업 파트너만 API를 사용할 수 있습니다.예를 들어, 우버나 리프트와 같은 고용 회사를 위한 차량은 승인된 타사 개발자가 앱 내에서 직접 탑승을 주문할 수 있도록 합니다.이를 통해 기업은 API에 액세스할 수 있는 앱을 큐레이션하여 품질 관리를 수행하고 추가적인 수익원을 제공할 수 있습니다.[46]
  • 공개 : 일반인이 사용할 수 있는 API입니다.예를 들어, 마이크로소프트는 윈도우 API를 공개하고, 애플은 자사의 플랫폼을 위해 소프트웨어를 작성할 수 있도록 카카오 API를 공개합니다.모든 공개 API가 일반적으로 누구나 접근할 수 있는 것은 아닙니다.예를 들어 Cloudflare나 Voxility와 같은 인터넷 서비스 공급자는 RESTful API를 사용하여 고객과 리셀러가 인프라 정보, DDoS 통계, 네트워크 성능 또는 대시보드 제어에 액세스할 수 있도록 합니다.[47]이러한 API에 대한 액세스 권한은 "API 토큰" 또는 고객 상태 확인을 통해 부여됩니다.[48]

공용 API의 시사점

API가 공개될 때 중요한 요소는 "인터페이스 안정성"입니다.예를 들어 함수 호출에 새 매개 변수를 추가하는 등 API를 변경하면 해당 API에 의존하는 클라이언트와의 호환성이 중단될 수 있습니다.[49]

공개적으로 제시된 API의 일부가 변경될 수 있으므로 안정적이지 않을 경우, 특정 API의 일부는 "불안정"으로 명시적으로 문서화되어야 합니다.예를 들어 Google Guava 라이브러리에서 불안정하다고 간주되고 곧 변경될 수 있는 부분은 Java 주석으로 표시됩니다. @Beta.[50]

공개 API는 때때로 자신의 일부를 더 이상 사용하지 않거나 취소된 것으로 선언할 수 있습니다.이는 일반적으로 API의 일부를 제거하거나 이전 버전과 호환되지 않는 방식으로 수정해야 한다는 것을 의미합니다.따라서 이러한 변경을 통해 개발자는 향후 제거되거나 지원되지 않는 API의 일부에서 벗어날 수 있습니다.[51]

2020년 2월 19일, 아카마이는 연례 "State of the Internet" 보고서를 발표하여 전 세계 금융 서비스의 공공 API 플랫폼을 대상으로 하는 사이버 범죄자의 증가 추세를 보여주었습니다.아카마이는 2017년 12월부터 2019년 11월까지 854억 2천만 건의 자격 증명 위반 공격을 목격했습니다.약 20%인 165억 5천만 명이 API 엔드포인트로 정의된 호스트 이름에 반대했습니다.이 중 4억7,350만 명이 금융 서비스 부문 조직을 대상으로 하고 있습니다.[52]

문서화

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

문서화는 API를 이용한 응용프로그램의 개발과 유지관리에 매우 중요합니다.[53]API 문서는 일반적으로 문서 파일에서 볼 수 있지만 블로그, 포럼 및 Q&A 웹 사이트와 같은 소셜 미디어에서도 볼 수 있습니다.[54]

전통적인 문서 파일은 대개 일관된 모양과 구조를 가진 문서 시스템(예: Javadoc 또는 Pydoc)을 통해 제공됩니다.그러나 설명서에 포함된 내용의 종류는 API마다 다릅니다.[55]

명확성을 위해 API 문서에는 API의 클래스 및 방법에 대한 설명과 함께 "일반적인 사용 시나리오, 코드 스니펫, 설계 이유, 성능 토론 및 계약"이 포함될 수 있지만, API 서비스 자체에 대한 구현 세부 사항은 생략되는 것이 일반적입니다.

REST API에 대한 참조 문서를 Open에서 자동으로 생성할 수 있습니다.API 문서, OpenAPI 사양에 정의된 지정된 형식과 구문을 사용하는 컴퓨터로 읽을 수 있는 텍스트 파일입니다.디 오픈API 문서는 API의 이름과 설명, API가 접근할 수 있는 작업에 대한 설명과 같은 기본 정보를 정의합니다.[56]

API 문서는 Java 주석과 같은 메타데이터 정보로 풍부해질 수 있습니다.이 메타데이터는 컴파일러, 도구 및 런타임 환경에서 사용자 지정 동작 또는 사용자 지정 처리를 구현하는 데 사용할 수 있습니다.[57]

API 저작권 보호 관련 분쟁

주요 기사:Oracle America, Inc. 대 Google, Inc.

2010년 오라클은 구글이 안드로이드 운영 체제에 내장된 자바의 새로운 구현을 배포한 것에 대해 고소했습니다.[58]Google은 비슷한 OpenJDK 프로젝트에 대한 허가를 받았음에도 불구하고 Java API를 복제할 수 있는 어떠한 허가도 받지 않았습니다.구글은 자사 API에 대한 라이선스 협상을 위해 오라클에 접근했지만 신뢰 문제 때문에 거절당했습니다.이견에도 불구하고, 구글은 어쨌든 오라클의 코드를 사용하기로 결정했습니다.William Alsup 판사는 Oracle v. Google 사건에서 API는 미국에서 저작권을 가질 수 없으며 Oracle이 승리할 경우 저작권 보호가 "기능적인 기호 집합"으로 광범위하게 확대될 것이며 간단한 소프트웨어 명령의 저작권을 허용할 것이라고 판결했습니다.

오라클의 주장을 받아들이는 것은 누구나 한 버전의 코드에 저작권을 부여하여 명령 시스템을 수행할 수 있도록 하고, 그에 따라 다른 모든 코드가 동일한 명령의 전부 또는 일부를 수행하기 위해 다른 버전을 작성하는 것을 금지하는 것입니다.[59][60]

알섭의 판결은 2014년 연방순회항소법원에 항소하여 뒤집혔지만, 그러한 API 사용이 공정한 사용에 해당하는지에 대한 문제는 해결되지 않았습니다.[61][62]

2016년, 2주간의 재판 끝에 배심원단은 Google의 Java API 재구현이 공정한 사용에 해당한다고 평결했지만, Oracle은 이 결정에 항소할 것을 약속했습니다.[63]오라클은 항소에서 승소했으며 연방 순회 항소 법원은 구글의 API 사용이 공정한 사용을 위한 자격이 없다고 판결했습니다.[64]2019년 구글은 저작권과 공정이용 판결에 대해 모두 미국 연방대법원에 항소하였고, 연방대법원은 검토를 허가하였습니다.[65]이 사건 구두심리는 코로나19 팬데믹으로 인해 2020년 10월까지 연기되었습니다.[66]

이 사건은 대법원이 6대 2의 판결로 구글의 손을 들어준 것입니다.스티븐 브라이어 판사는 법원의 의견을 전달하면서 "선언 코드는 저작권이 있다면 저작권의 핵심에서 나오는 대부분의 컴퓨터 프로그램보다 더 멀리 있다"고 언급했습니다.이것은 API에 사용되는 코드가 저작권 보호 측면에서 소설보다는 사전과 더 유사하다는 것을 의미합니다.[67]

예

주요 카테고리: 응용 프로그램 인터페이스

참고 항목

참고문헌

  1. ^ Reddy, Martin (2011). API Design for C++. Elsevier Science. p. 1. ISBN 9780123850041.
  2. ^ a b Lane, Kin (October 10, 2019). "Intro to APIs: History of APIs". Postman. Retrieved September 18, 2020. 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. ^ Wood, Laura (2021-08-25). "Global Cloud Microservices Market (2021 to 2026)". businesswire.com. Retrieved 2022-03-29.
  4. ^ a b c Clarke, Steven (2004). "Measuring API Usability". Dr. Dobb's. Retrieved 29 July 2016.
  5. ^ a b Database architectures – a feasibility workshop (Report). Washington, DC: U.S. Department of Commerce, National Bureau of Standards. April 1981. pp. 45–47. hdl:2027/mdp.39015077587742. LCCN 81600004. NBS special publication 500-76. Retrieved September 18, 2020.
  6. ^ a b c d Bloch, Joshua (August 8, 2018). A Brief, Opinionated History of the API (Speech). QCon. San Francisco: InfoQ. Retrieved September 18, 2020.
  7. ^ a b 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. Vol. I. San Francisco, California: Association for Computing Machinery. pp. 533–544. doi:10.1145/1476589.1476661. ISBN 978-1450378994. OCLC 1175621908.
  8. ^ "application program interface". Oxford English Dictionary (Online ed.). Oxford University Press. (가입 또는 참여기관 회원가입 필요)
  9. ^ Date, C. J. (2019). E. F. Codd and Relational Theory: A Detailed Review and Analysis of Codd's Major Database Writings. Lulu.com. p. 135. ISBN 978-1684705276.
  10. ^ Date, C. J.; Codd, E. F. (January 1975). "The relational and network approaches: Comparison of the application programming interfaces". In Randall Rustin (ed.). Proceedings of 1974 ACM-SIGMOD Workshop on Data Description, Access and Control. SIGMOD Workshop 1974. Vol. 2. Ann Arbor, Michigan: Association for Computing Machinery. pp. 83–113. doi:10.1145/800297.811532. ISBN 978-1450374187. OCLC 1175623233.
  11. ^ Carl, Malamud (1990). Analyzing Novell Networks. Van Nostrand Reinhold. p. 294. ISBN 978-0442003647.
  12. ^ a b Jin, Brenda; Sahni, Saurabh; Shevat, Amir (2018). Designing Web APIs. O'Reilly Media. ISBN 9781492026877.
  13. ^ Fielding, Roy (2000). Architectural Styles and the Design of Network-based Software Architectures (PhD). University of California, Irvine. Retrieved September 18, 2020.
  14. ^ Dotsika, Fefie (August 2010). "Semantic APIs: Scaling up towards the Semantic Web". International Journal of Information Management. 30 (4): 335–342. doi:10.1016/j.ijinfomgt.2009.12.003.
  15. ^ Odersky, Martin; Spoon, Lex; Venners, Bill (10 December 2008). "Combining Scala and Java". www.artima.com. Retrieved 29 July 2016.
  16. ^ de Figueiredo, Luiz Henrique; Ierusalimschy, Roberto; Filho, Waldemar Celes (1994). "The design and implementation of a language for extending applications". TeCGraf Grupo de Tecnologia Em Computacao Grafica: 273–284. CiteSeerX 10.1.1.47.5194. S2CID 59833827. Retrieved 29 July 2016.
  17. ^ Sintes, Tony (13 July 2001). "Just what is the Java API anyway?". JavaWorld. Retrieved 2020-07-18.
  18. ^ Winters, Titus; Tom Manshreck; Hyrum Wright, eds. (2020). Software engineering at Google: lessons learned from programming over time. Sebastopol, CA. ISBN 9781492082798. OCLC 1144086840.{{cite book}}: CS1 유지 관리: 위치 누락 게시자(링크)
  19. ^ 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. OOPSLA 2015. New York, NY, USA: Association for Computing Machinery. pp. 695–710. doi:10.1145/2814270.2814313. ISBN 978-1-4503-3689-5.
  20. ^ Mclaughlin, Stefano (20 December 1996). "What You Should Know About Standards, APIs, Interfaces and Bindings". washingtonindependent.com.
  21. ^ "F2PY.org". F2PY.org. Retrieved 2011-12-18.
  22. ^ Fowler, Martin. "Inversion Of Control".
  23. ^ Fayad, Mohamed. "Object-Oriented Application Frameworks".
  24. ^ Lewine, Donald A. (1991). POSIX Programmer's Guide. O'Reilly & Associates, Inc. p. 1. ISBN 9780937175736. Retrieved 2 August 2016.
  25. ^ West, Joel; Dedrick, Jason (2001). "Open source standardization: the rise of Linux in the network era" (PDF). Knowledge, Technology & Policy. 14 (2): 88–112. doi:10.1007/PL00022278. S2CID 46082812. Retrieved 2 August 2016.
  26. ^ Microsoft (October 2001). "Support for Windows XP". Microsoft. p. 4. Archived from the original on 2009-09-26.
  27. ^ "LSB Introduction". Linux Foundation. 21 June 2012. Archived from the original on 2015-04-02. Retrieved 2015-03-27.
  28. ^ Stoughton, Nick (April 2005). "Update on Standards" (PDF). USENIX. Retrieved 2009-06-04.
  29. ^ Bierhoff, Kevin (23 April 2009). API Protocol Compliance in Object-Oriented Software (PDF) (PhD). Carnegie Mellon University. ISBN 978-1-109-31660-5. ProQuest 304864018. Retrieved 29 July 2016.
  30. ^ Wilson, M. Jeff (10 November 2000). "Get smart with proxies and RMI". JavaWorld. Retrieved 2020-07-18.
  31. ^ Henning, Michi; Vinoski, Steve (1999). Advanced CORBA Programming with C++. Addison-Wesley. ISBN 978-0201379273. Retrieved 16 June 2015.
  32. ^ Benslimane, Djamal; Schahram Dustdar; Amit Sheth (2008). "Services Mashups: The New Generation of Web Applications". IEEE Internet Computing, vol. 12, no. 5. Institute of Electrical and Electronics Engineers. pp. 13–15. Archived from the original on 2011-09-28. Retrieved 2019-10-01.
  33. ^ Niccolai, James (2008-04-23), "So What Is an Enterprise Mashup, Anyway?", PC World[영구 데드링크]
  34. ^ Parr, Ben (21 May 2009). "The Evolution of the Social Media API". Mashable. Retrieved 26 July 2016.
  35. ^ "GET trends/place". developer.twitter.com. Retrieved 2020-04-30.
  36. ^ Garlan, David; Shaw, Mary (January 1994). "An Introduction to Software Architecture" (PDF). Advances in Software Engineering and Knowledge Engineering. 1. Retrieved 8 August 2016.
  37. ^ Parnas, D.L. (1972). "On the Criteria To Be Used in Decomposing Systems into Modules". Communications of the ACM. 15 (12): 1053–1058. doi:10.1145/361598.361623. S2CID 53856438.
  38. ^ Myers, Brad A.; Stylos, Jeffrey (2016). "Improving API usability". Communications of the ACM. 59 (6): 62–69. doi:10.1145/2896587. S2CID 543853.
  39. ^ 브라이언 엘리스, 제프리 스타일로스, 브래드 마이어스.2007. API 설계에서의 공장 패턴:사용성 평가.제29회 소프트웨어 공학 국제 회의(ICSE '07)의 의사록.IEEE 컴퓨터 학회, 미국, 302-312.DOI: https://doi.org/10.1109/ICSE.2007.85 http://www.cs.cmu.edu/ ~NatProg/papers/Ellis 2007FactoryUsability.pdf
  40. ^ 동기 대.비동기식 쓰기 - Packed Contact Center Enterprise - 문서 - Cisco DevNet
  41. ^ Silva, Paulo (2019). "Global Cloud Microservices Market (2021 to 2026)". Retrieved 2022-03-29.
  42. ^ "Web Security". 2022-02-18. Retrieved 2022-03-29.
  43. ^ "API Keys – What Is an API Key? APILayer Blog". 2022-03-01. Retrieved 2022-07-15.
  44. ^ de Ternay, Guerric (Oct 10, 2015). "Business Ecosystem: Creating an Economic Moat". BoostCompanies. Retrieved 2016-02-01.
  45. ^ Boyd, Mark (2014-02-21). "Private, Partner or Public: Which API Strategy Is Best for Business?". ProgrammableWeb. Retrieved 2 August 2016.
  46. ^ Weissbrot, Alison (7 July 2016). "Car Service APIs Are Everywhere, But What's In It For Partner Apps?". AdExchanger.
  47. ^ "Cloudflare API v4 Documentation". cloudflare. 25 February 2020. Retrieved 27 February 2020.
  48. ^ Liew, Zell (17 January 2018). "Car Service APIs Are Everywhere, But What's In It For Partner Apps". Smashing Magazine. Retrieved 27 February 2020.
  49. ^ Shi, Lin; Zhong, Hao; Xie, Tao; Li, Mingshu (2011). "An Empirical Study on Evolution of API Documentation". Fundamental Approaches to Software Engineering. pp. 416–431. doi:10.1007/978-3-642-19811-3_29. ISBN 978-3-642-19810-6. Retrieved 22 July 2016. {{cite book}}: work=무시됨(도움말)
  50. ^ "guava-libraries – Guava: Google Core Libraries for Java 1.6+ – Google Project Hosting". 2014-02-04. Retrieved 2014-02-11.
  51. ^ Oracle. "How and When to Deprecate APIs". Java SE Documentation. Retrieved 2 August 2016.
  52. ^ Takanashi, Dean (19 February 2020). "Akamai: Cybercriminals are attacking APIs at financial services firms". Venture Beat. Retrieved 27 February 2020.
  53. ^ 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.
  54. ^ 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. pp. 25–30. doi:10.1145/1984701.1984706. ISBN 9781450305952. S2CID 17751901. {{cite book}}: journal=무시됨(도움말)
  55. ^ Maalej, Waleed; Robillard, Martin P. (April 2012). "Patterns of Knowledge in API Reference Documentation" (PDF). IEEE Transactions on Software Engineering. Retrieved 22 July 2016.
  56. ^ "Structure of an OpenAPI Document". OpenAPI Documentation. Retrieved 2022-11-06.
  57. ^ "Annotations". Sun Microsystems. Archived from the original on 2011-09-25. Retrieved 2011-09-30..
  58. ^ "Oracle and the End of Programming As We Know It". DrDobbs. 2012-05-01. Retrieved 2012-05-09.
  59. ^ "APIs Can't be Copyrighted Says Judge in Oracle Case". TGDaily. 2012-06-01. Retrieved 2012-12-06.
  60. ^ "Oracle America, Inc. vs. Google Inc." (PDF). Wired. 2012-05-31. Retrieved 2013-09-22.
  61. ^ "Oracle Am., Inc. v. Google Inc., No. 13-1021, Fed. Cir. 2014". Archived from the original on 2014-10-10.
  62. ^ Rosenblatt, Seth (May 9, 2014). "Court sides with Oracle over Android in Java patent appeal". CNET. Retrieved 2014-05-10.
  63. ^ "Google beats Oracle – Android makes "fair use" of Java APIs". Ars Technica. 2016-05-26. Retrieved 2016-07-28.
  64. ^ Decker, Susan (March 27, 2018). "Oracle Wins Revival of Billion-Dollar Case Against Google". Bloomberg Businessweek. Retrieved March 27, 2018.
  65. ^ Lee, Timothy (January 25, 2019). "Google asks Supreme Court to overrule disastrous ruling on API copyrights". Ars Technica. Retrieved February 8, 2019.
  66. ^ vkimber (2020-09-28). "Google LLC v. Oracle America, Inc". LII / Legal Information Institute. Retrieved 2021-03-06.
  67. ^ "Supreme Court of the United States, No. 18–956, GOOGLE LLC, PETITIONER v. ORACLE AMERICA, INC" (PDF). April 5, 2021.

추가열람

외부 링크