대화:API

구식 출품.

Sunit Pinto는 API를 개발하고 있다.

잠깐만, SNMP는 API가 아니야? 그것은 의전이다. CORBA에 대해서는 잘 모르지만, DCOM을 API라고 부르지 않을 것이다. 2004년 2월 16일 (UTC) 로브닐드 15:53

이 문서 상단의 정의는 프로토콜이 API로 간주될 결과와 함께 너무 포괄적이다. 이 용어의 일반적인 용어는 계급이나 기능의 집합에 사용된다. CORBA는 많은 것(프로토콜, 언어 매핑, 유형 시스템...)이며, OBR API도 포함되어 있다. 그러나 대부분의 사람들은 CORBA를 API라고 부르지 않을 것이다. 기껏해야 API를 표현하는 언어다. 야론프 23:31, 2004년 2월 18일 (UTC)

API에 대한 너의 정의는 너무 포괄적이다. API는 그 프로그래밍 언어로 사용자에게 제공되는 프로그래밍 언어 인터페이스다. 이것은 대개 실제 통신의 "와이어" 형식을 나타내는 프로토콜과는 다르다. 이것은 가능한 웹 인터페이스, CORBA의 IIOP 또는 소켓 호출에 사용되는 규약일 수 있다. 이를 XML과 온톨로지로 표현하는 것은 프로토콜의 다음 진화일 뿐 API의 진화는 아니다. 나는 API가 기본적으로 다음 N 제곱 문제를 만들어 낼 때 API를 최소화해야 한다고 주장하는데, 이는 모든 언어로 구현될 수 있도록 하기 위해, 변화를 만들기는커녕 매우 힘든 싸움을 하게 된다. 반면에, 프로토콜은 진화할 수 있고, 당신은 언어가 프로토콜을 만드는 방법을 찾도록 한다. 온톨로지에 대한 참조는 프로토콜에는 적합하지만 API에는 적합하지 않다.

너무 기술적인

이 글은 컴퓨터 지향적인 사람치고는 너무 기술적이다. 도입부를 완전히 다시 작성해 기술적 세부사항을 하위 섹션으로 격하시킬 필요가 있다. 물론 시간이 없다...195.176.162.18 (토크) 07:00, 2008년 9월 2일 (UTC)[]

됐어. 새로운 리드에 대한 피드백/편지가 좋을 것 같아. – FenixFeather 00:04, 2016년 7월 23일(UTC)[]

API 카테고리

카테고리를 만들까 생각 중이었습니다.응용 프로그램 프로그래밍 인터페이스, 위키백과에 존재하는 모든 API에 대한 reposity 생성(DirectX, win32, opengl 등)

• 나는 Jontce 14:53, 2005년 11월 15일 (UTC)[]이라는 아이디어가 좋다.
• 더 좋은 코너를 찾을 수 없었고 댓글을 다는 것도 처음이라 여기에 댓글을 달았다. 내 생각이 적절하지 않다면 미리 사과하겠다. 나는 이 기사에서 ABI의 과대 설명에 대해 언급하고 싶었다. 누군가는 돌아가서 그걸 치워야 해. ABI가 설명에서 중요한 역할을 한다면 그렇게 하겠지만, ABI를 설명하는 다른 위키백과로 연결되는 링크만 있으면 된다. API나 ABI 뒤에 숨겨진 기본 개념을 모두 이해하지 못하는 사람에게, 여기에 있는 ABI의 추가 정보는 그야말로 나를 미치게 했다. —Chrisban35(대화 • 기여) 13:52, 2009년 3월 29일(UTC)[]에 의해 추가된 서명되지 않은 논평 준비

약간의 혼란...

바보같이 들릴지 모르지만 API와 도서관의 차이점은 무엇인가?

API는 인터페이스일 뿐이다. —80.38.67.99 (대화) 09:06, 2008년 6월 16일 (UTC)[]에 의한 서명되지 않은 의견 추가 준비

---

간단히 말해서, API는 도서관이 그 계약을 이행하는 동안 준수하기 위한 계약이다.

내 경험상 'API'라는 용어는 도서관, 그 인터페이스, 그리고 '계약'을 의미하기 위해 상호 교환적으로 사용된다. 특히 Java API에 대해 생각하고 있어. --UTC (토크) 23:25, 2009년 1월 7일 (UTC)[]

그건 아직도 말이 안 돼. 너희들이 정말로 말하고 있는 것은 상징적인 조립자가 디스크에서 꺼내서 가공하고 실행 가능한 객체 코드를 생성하는 기호 라벨(때로는 확장 가능한 매크로 포함)의 표라고 나는 생각한다. 좋은 조립자는 다른 사람의 라벨 표를 가져와 다른 사람의 소스 코드와 혼합할 수 있게 하며, 코드를 생성하기 전에 첫 번째 조립 패스를 우회할 수 있다. 만약 당신이 말하는 것이 그것이라면, API의 개념은 완전히 환상적이다. 실행 컨텍스트는 실제로 어떤 마이크로프로세서와 함께 작업하고 있는지, 특히 I/O 라인이 어떻게 처리되고 있는지에 따라 달라진다. 예를 들어, 극도로 제한된 스택을 가진 마이크로프로세서들이 있는데, 나는 당신의 API라고 불리는 것 중 하나가 그것들과 함께 작동할지 의심스럽다. Dexter Nextnumber (talk) 04:09, 2009년 12월 21일 (UTC)[]

굵게 표시된 텍스트== 프레임워크, API, 라이브러리, 프로토콜 ==

친애하는 여러분,

특히 문서는 현재 존재하는 것보다 더 많은 인용문을 사용할 수 있으며, 가능하다면 덜 기술적인 정의를 사용할 수 있다. 아니면 그 문제에 대해서, 단순히 코드에서 무슨 일이 일어나고 있는지에 대한 좀 더 평이한 사람의 설명으로 하자.

친애하는 여러분,

       내 생각에 여기선 이해하기가 너무 그리운 것 같아. 

첫째로 프로그래머와 시스템 분석가는 우리가 이 피라미드에 대해 이야기하고 있다는 것을 알 수 있다.

                 -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 

---

운영 체제 계층->프로토콜--> 운영 체제

프로그래머들은 대개 특정 운영체제에 기초해야 하는 특정 프레임워크의 일부인 APIs에 대한 호출을 이용하여 그들만의 라이브러리를 만들고, 운영체제는 다른 운영체제와의 통신을 관리하기 위해 프로토콜을 사용한다.

예를 들어, 다음과 같은 경우:

---

프로그램------------------------------------------------------------

프로그래머가 도서관을 만들었어 어떤 일이든...NET API(시스템).윈도, 시스템.창문들양식... 등)

---

.NET Framework--------------------------------

---

Windows XP----------------------------------------------------

호삼 압바스에게 안부 전하다

---

저 피라미드는 기만적이다. 단일 API가 여러 라이브러리에 분산되거나, 하나의 라이브러리가 여러 API를 구현하는 것이 가능하다. API는 일반적으로 프로그램과 라이브러리 사이 또는 두 라이브러리 사이 또는 '플러그인'과 프로그램 사이의 인터페이스에 대한 규격이다. API는 실제 라이브러리라기보다는 문서화에 가깝다. 단일 API는 여러 구현, 즉 여러 라이브러리에 적용할 수 있다. nVidia의 OpenGL 구현과 Mesa OpenGL 구현 모두를 연결하는 OpenGL 애플리케이션을 작성할 수 있다. 동일한 API의 두 가지 구현. API라는 개념이 필요한 이유는 라이브러리라는 단어가 통하지 않기 때문이다.

SteveBaker 14:41, 2006년 2월 2일 (UTC)[]

링크가 너무 많아.

예제 API에 대한 링크가 모두 필요한 것 같지는 않다. 링크 스팸에 위험할 정도로 가까워지고 있다. 또한 WP:MOS는 참고문헌에 대한 외부 링크만 사용하거나(우리의 링크는 아님) 기사나 다른 위키백과 기사에 적절하게 설명되지 않은 내용을 다룰 것을 권고한다. 예시 API에 대한 내부 링크 목록이 좋기 때문에, 나는 모든 외부 사례를 삭제하려고 한다.

API의 예시 목록에는 2개의 외부 링크가 있다(미디어위키와 드루팔). 외부 링크는 외부 링크 섹션에 배치되어야 하기 때문에 프로젝트 페이지에 대한 내부 링크로 교체할 것을 제안한다. 외부 Drupal API 링크는 Drupal에 이미 존재하며, 외부 MediaWiki API 링크는 MediaWiki로 이동할 수 있다. --Luen (talk) 09:45, 2008년 12월 5일 (UTC)[]

그 문제에 대한 나의 느낌은 만약 API가 그것 자체의 페이지를 가지고 있을 만큼 충분히 중요하지 않다면, 그것은 API와는 무관하게, 우리는 아마도 그것과 연결되지 말아야 할 것이다. 그래서 이 두 링크와 맨 오른쪽 열의 다른 모든 링크와 아이폰 API를 삭제하겠다. JuleS (talk) 2008년 12월 6일 16:19 (UTC)[]

이 기사는 특집 기사 상태를 다시 확인할 필요가 있다. SteveBaker 22:21, 2006년 3월 31일 (UTC)[]

응용 프로그램 프로그래밍 인터페이스 또는 응용 프로그램 인터페이스

단지 확인하기 위해서; 기술적으로 그것은 응용 프로그램 프로그래밍 인터페이스인가 아니면 응용 프로그램 인터페이스인가? 이것이 매우 까다롭다는 것은 알지만 백과사전은 그것을 바로 잡아야 한다. (제발 나를 불살라주지 마십시오.) 고마워 --Skoorb 17:26, 2006년 4월 1일 (UTC)[]

프로그래밍 작업이 완료된 후에도 애플리케이션과 라이브러리 사이에 인터페이스가 남아 있기 때문에 애플리케이션 프로그램 인터페이스라고 생각한다. 모든 프로그래밍이 완료된 후 API를 정의할 수도 있다. 예를 들어 API를 위한 사양을 적었을 때만 기존 응용프로그램의 일부를 분리하여 라이브러리로 만들 수 있다고 결정할 때 말이다. 하지만, 그것은 작은 것이다 - 그리고 이것은 점차적으로 자리잡은 비공식적인 용어들 중 하나이기 때문에, 어떤 사용자들은 하나의 의미를, 다른 사용자들은 그 반대 입장을 취하는 것이 완벽하게 가능하다. SteveBaker 17:34, 2006년 4월 1일 (UTC)[]

나는 추상 프로그래밍 인터페이스로 정의된 API를 본 적이 있다. ChopMonkey 15:08, 2006년 10월 2일 (UTC)[]

IMHO가 가장 의미 있게 사용되는 또 다른 용어는 개발자가 새로운 애플리케이션을 작성하기 위한 인터페이스인 '응용프로그램 프로그래머 인터페이스'이다.

위의 코멘트에도 동의한다, '응용프로그램 프로그래머 인터페이스'도 자주 사용된다. 88.255.168.161 08:17, 2007년 6월 26일 (UTC)[]

"API는 프로그래머에게 최종 사용자에게 GUI가 무엇인지입니다. API의 'P'는 '프로그램'이 아닌 '프로그래머'를 뜻하는 말로 API가 인간인 프로그래머가 사용한다는 사실을 부각시킨다. 아마도 API가 다른 해석으로 이어지는 다른 데크로니엠을 가지고 있다는 사실에 대한 언급이 있어야 할 것이다. 85Pando (대화) 11:34, 2010년 5월 7일 (UTC)[]

IETF RFCs, IEEE 및 많은 다른 명성 높은 출처는 그것을 "응용프로그램 프로그래머 인터페이스"로 분류한다. 이것은 내가 대학원 학위를 받은 메릴랜드 대학에서 가르치는 탈선이다. 이 글에서 제시된 브레이크아웃은 실수다. - --사용자:aja12aja 21:13, 2013년 12월 26일 (UTC)[]

API 리디렉션

에드콜린스 왜 이걸 복구하려 하십니까? API는 이 페이지로 리디렉션되지 않고 disabigation 페이지로 이동한다. 해봐.jbolden1517^Talk 18:26, 2006년 5월 5일 (UTC)[]

API는 여기서가 아닌 혼란으로 리디렉션되어야 한다. 우리 분야에서 흔하다고 해서 독점하는 것은 다른 학문에도 전혀 불공평하다. --트리키즈 19:25, 2007년 10월 1일 (UTC)[]

발음

그래서 대부분의 사람들은 API를 어떻게 발음할까? P I, appie?

나—그리고 나와 함께 일한 모든 프로그래머들은 그것을 "A"와 "하루"에, "Pea in a pod"에, 그리고 "I"를 "I love you."에서와 같이 발음한다.HTH — 주근깨발톡 14:30, 2006년 8월 29일 (UTC)[]

"appie"는 다른 단어들과 너무 쉽게 혼동되는데, 그들 중 다수는 감정적이다. 프로그래머들은 그것을 싫어한다;-) --트리키즈 19:31, 2007년 10월 1일 (UTC)[]

개방 대 폐쇄

API가 "개방형"일 때와 "폐쇄형"일 때를 비교하여 더 나은 설명을 듣고 싶다. 현재의 정의는 사용권과 소스 코드에 대한 접근에 초점을 맞추고 있지만, 그 생각은 그보다 더 넓다고 생각한다. 예를 들어, API는 명확하게 문서화되어 있고 정의된 프로세스를 통해 확장될 수 있을 때 "열림"도 된다고 생각한다. 나는 또한 표준화가 이 논의에서 한 몫을 한다고 생각한다. 생각? --Mwfnwa 13:00, 2006년 9월 5일 (UTC)[]

---

나는 이 측면이 일을 필요로 한다는 것에 동의한다. 중요한 것은 접근과 응용에 대한 재정적 비용이다. 누가 접속할 수 있는지에 대한 문제제기를 하는 것은 어떨까? 내가 이해한 바와 같이, 오픈 api(또는 모든 오픈 기술)는 모든 참가자들에게 동등하게 개방되어 있다.

즉, 내 기술을 친구에게 무료로 제공하고, 다른 사람에게 요금을 청구하며, 내가 잠재적 경쟁자로 간주하는 사람들에게 전혀 이용하지 못하게 한다면, 내 기술(api 또는 not or not)은 개방되지 않는다. (표준기관 중 하나가 이것을 "개방형 표준"에 대한 정의의 중요한 부분으로 만든다는 것을 상기하는 것 같다. 즉, 수수료가 있는지 여부가 아니라, 같은 것을 지불할 의향이 있는 사람과 같은 가격에 이용할 수 있는지 여부도 마찬가지다.) - ef

다국어 API

DOM과 같이 언어에 독립적인 API의 예를 갖추어야 하지 않을까?:

Document Object Model은 프로그램 및 스크립트가 문서의 내용, 구조 및 스타일에 동적으로 액세스하고 업데이트할 수 있는 플랫폼 및 언어 중립 인터페이스다. (http://www.w3.org/DOM/)부터

제발, 적어도 "API"의 다른 의미인 능동 의약품 성분도 있다는 것을 받아들이지 마십시오. 어떻게 해야 할지 모르지만, 위키에서 언급해야 한다고 생각한다. 안녕히 계세요

API가 되기 위한 소스 코드 정의?

나는 API가 소스 코드 레벨에서만 정의될 수 있다는 것이 사실이라고 생각하지 않는다. 나는 이 정의를 사용하는 믿을 만한 출처가 보이지 않는다(이 글의 중복과 명백한 사본을 삭제하는 구글 검색은 아무 쓸모도 없는 것으로 판명된다). 더욱이, 나는 소스 코드가 지정되지 않은 상세 정보, 예를 들어 Win32 API가 마이크로소프트의 구조화된 예외 처리 구현에 의존하는 것, MS-DOS API(특정 값으로 초기화해야 하는 레지스터 세트와 p를 수행하기 위해 실행되어야 하는 기계 지침)를 포함하는 API의 많은 예를 본다.관절함수 - 이를 참조하기 위해 API라는 용어가 사용된다는 증거는 [1]을 참조하십시오). 다음 문장에서 소스 코드가 API를 정의하는 일반적인 방법임을 분명히 할 때, "소스 코드" 구문을 정의에 포함시키는 것에 대한 내성은 단순히 자원하지 않은 POV 삽입일 뿐이다.

일부 공급업체 API에는 일반적으로 ABI의 일부로 간주되는 정보가 포함되어 있다는 것이 옳다. 벤더측의 의도는 별도의 API와 ABI 문서를 보유하는 것이 아니라 하나의 문서를 제작하는 것이 아닌가 하는 생각이 든다. 이 판매업자의 용법은 기사에 언급되어야 한다. 여러 가지 면에서 마이크로소프트 API는 윈도우에 크게 묶여 있으며 API 베니어(vener)를 가진 ABI라고 불릴 수 있다. 나는 API에서 P를 가리키고 있는데, 그것은 프로그래밍 인터페이스다; 소프트웨어를 작성할 때, 즉 소스 코드를 쓸 때 사용된다. 데릭 파른 2007년 8월 6일 (UTC)[]

나는 그것의 포함을 찬성하는 사람들에게 그것을 정당화할 수 있는 기회를 주기 위해 그것을 다시 제거하지는 않을 것이다. 하지만 나는 그들이 힘든 일을 할 것이라고 생각한다. JulesH 14:49, 2007년 8월 6일 (UTC)[]

소스 코드가 제공되지 않을 때, API 정의가 거의 항상 모호하고 구체화되지 않는다는 현실적인 문제가 여기에 있다. 간단히 말해서, 블랙 박스 매핑은 결코 이러한 경우에 실제로 지정되지 않으며, 매핑이 명확하지 않게 정의되지도 않는다( API가 소스 코드와 오픈 소스 빌드 툴 체인을 동반할 때와 대조적으로, http://cm.bell-labs.com/who/ken/trust.html). 호젤다 (토크) 00:27, 2009년 1월 30일 (UTC)[]

중간 추상화를 도입하지 않고 컴포넌트/도서관/원격 시스템 동작과 직접 인터페이스할 수 있는 도구를 프로그래머에게 주지 않는 경우, API 이외의 것이 있다. 프로그래머가 사용할 수 있는 프로그램 인터페이스(API!)가 필요하며, 인터페이스는 일반적인 목적 "여기 소켓이 있어, 이 구조로 이 순서대로 패키지를 전송하라"가 아니라 직접 인터페이스여야 한다. 후자는 전송 프로토콜이다. JSON을 사용하는 RESTful 웹 서비스가 있는 경우, 플랫폼이 프로토콜 세부사항을 추상화할 수 있는 경우에만 API를 사용할 수 있다. 그렇지 않으면, 그것은 단지 당신이 하고 있는 웹 서비스 전화일 뿐인데, 틀림없이 당신을 돕기 위해 다른 중간 API를 사용하는 것이다(소켓, HTTP 등). 72.142.11.38 (대화) 15:24, 2017년 6월 13일 (UTC)[]

품질 저하

나는 이 버전의 기사가 현재의 기사보다 여러 면에서 우수하다는 것을 주목한다. 비전문가가 비교적 이해하기 쉬운 용어로 기술된 API의 좋은 예를 들어(개선될 수도 있었지만 단순하게 삭제된 것처럼), 텍스트가 더 잘 쓰여진 것처럼 보이기 때문에 이해하기가 더 쉽다. 왜 우리는 완벽하게 합리적인 기사를 파괴했는가? JulesH 14:55, 2007년 8월 6일 (UTC)[]

Ditto! 현재 기사는 너무 기술적이다. 그리고 난 방금 그걸 위한 범주가 있다는 걸 봤어! 나이스! 딸기섬 (토크) 21:56, 2008년 2월 13일 (UTC)[]

와우, 도입부 첫 단락에서 "inculcate"라는 단어가 사용되었구나! 어떤 사람이 거기서 말하려고 하는 것을 더 간단한 말로 묘사할 수 있는 방법을 찾을 수 없을까? 위키피디아의 단순화된 영어 버전에 없는 건 알지만, 난 원어민이고, 단어를 찾아봐야 했고, 거기서 무슨 말을 하려 했는지 아직도 모르겠어. 이 기사를 보고 있는 대부분의 사람들은 대학 영어 전공과 프로그래머의 결합이 되지 않을 것이다.Mmortal03 (대화) 10:48, 2008년 2월 25일 (UTC)[]

이 글의 이전 버전에서는 API의 [원래] 목적은 표준 언어로 코딩된 애플리케이션을 허용하고 표준 API[예: POSIX]를 사용하여 동일한 언어와 API를 제공하는 다른 플랫폼에 쉽게 포팅할 수 있는 기능을 허용하는 것임을 분명히 했다. API라는 용어가 유래한 1990년대 초반과 동시에 프로그램 이식성을 위한 또 다른 솔루션으로서 [예: 자바]를 탐색하고 있었다. 그 약어는 의미 풍부한 용어를 희석하는 쓸모없는 발전으로 간주되는 "모든 인터페이스"와 "인터페이스의 모든 방법 서명"을 의미하게 되었다. 휴대성의 진화를 묘사하고 과거의 교훈에 대해 말하는 것은 이제 불가능해졌다. 실망스럽다. 영어 원어민으로서(한 손에는 책을, 다른 한 손에는 사전을 들고 어린 시절을 많이 보낸 사람) 의미/언어에서의 부정의 제거에 대한 논의에 접선하면서, 나는 어휘를 확장하기 위해 1분이라도 시간을 들이고 싶지 않다는 것을 인정하기 부끄러울 것이다. wiktionary.org/wiki/<word> – --Koan911 (대화) 03:05, 2017년 4월 3일 (UTC)[]을 추천한다.

불화

히히

설명 페이지 정리하는 중...API용(동음이의)은 500개 이상의 링크가 있고 99% 이상이 이 페이지를 위한 것이다...과거에 이것에 대해 논의된 적이 있는 것 같은데...우리는 프로그래밍 언어가 유일한 또는 심지어 BEST 정의라고 말하는 것이 아니라, 사람들이 검색 상자에 API를 입력할 때 가장 많이 찾는 것이다. 그러니 내가 리디렉션을 할 수 있도록 허락해 주시고 이 페이지에 해트노트를 올려주시겠습니까? 이해해 주셔서 감사합니다. 레고텍 (토크) 17:49, 2008년 2월 23일 (UTC)[]

'원격 프로시저 호출' 용어의 명확화 요청

여보세요

언어 독립형 API에 대해 언급된 내용을 인용하고자 한다 - "언어 독립형 API는 여러 프로그래밍 언어에서 호출할 수 있는 방식으로 작성된다. 이는 특정 프로세스나 시스템에 구속되지 않고 원격 프로시저 호출로 이용할 수 있는 서비스형 API에 필요한 기능이다."

이것이 나와 같은 상대적으로 새로 온 사람에게 시사하는 바는 API를 쓸 수 있다는 겁니다. API는 어떤 언어로 작성되든 액세스할 수 있다는 겁니다. 그러나 '원격 프로시저 호출'에 대한 http://en.wikipedia.org/wiki/Remote_procedure_call 기사를 읽고 나면, '원격 프로시저 호출'은 컴퓨터가 물리적으로 원격 컴퓨터에서 병렬로 실행할 현재 실행 중인 프로그램의 하위 프로그램 중 하나를 가질 수 있는 메커니즘이라는 생각이 든다. 그리고 그것은 분산 컴퓨팅의 패러다임이라고 기사에 분명히 기술하고 있다. 그러므로 누구라도 이것이 '언어 독립형 API'와 어떻게 관련이 있는지 설명해 줄 수 있는가? 어떤 시나리오는 여기에서 도움이 될 것이다.Aijazbaig1 (토크) 11:38, 2008년 7월 15일 (UTC)[]

API

As a technical writer working on APIs, it seems to me that a bit of grammar help might be a good idea in this article; too often "API" is used to mean one call of many that make up an API and thus too much documentation uses "APIs" where one API (consisting of a multitude of API calls/functions) is meant. --iFaqeer (talk) 11:31, 17 July 2008 (UTC)[]

• 네 말이 맞아. 또한 API는 장소에서도 적합할 수 있다. 네가 편집하기에 이상적인 사람인 것 같아. 데릭 파른 (대화) 13:29, 2008년 7월 17일 (UTC)[]

API 관리(웹 서비스)

이 섹션은 거의 정의상 API에 관한 것이 아니라, API가 더 큰 규모의 소프트웨어 기업에 어떻게 적합한지에 관한 것이다. 나는 그것이 웹 서비스나 그런 것들로 인해 더 나을 것이라고 생각한다. 이 글에는 온갖 문제가 있지만(예: 너무 웹 중심적이라고 생각한다) 새로운 섹션은 선의로 다른 곳에 속한다고 생각한다.

아마 별도의 기사를 넣은 다음 메인이나 다른 것을 사용하여 링크할 수 있을까?

행복을 빌며

SimonTrew (대화) 2009년 4월 20일 16:33 (UTC)[]

나는 우리가 아마도 웹 서비스 API에 대한 대부분의 언급에서 이 기사를 삭제해야 한다고 생각한다. 그것들은 근본적으로 다르며, API보다는 프로토콜로 더 잘 생각되고 있다. 확실히 그들은 리드 섹션의 주제에 대한 설명에 맞지 않는다. JulesH (talk) 2009년 4월 20일 16:54 (UTC)[]

나는 대략 동의한다; 나는 그들이 완전히 무관하지는 않다. 하지만 대부분의 시간들이 그들이 매우 넓은 수준에서 익숙해지고 있다는 것에 동의한다. 예를 들어, 구글 맵 API는 IPI를 염두에 두고 있다. 당신은 XML이나 SOAP 같은 것을 잘 알고 있는 엔드포인트에 제출한다(어떤 종류의 URL, 내가 생각하는 http 주소) 그리고 당신이 맵에서 기대하는 다른 것들을 조정하고 확장해야 한다. 아니면 구글 검색 API가 더 간단하고 좋을 것이다. 하지만 "Google"은 API가 아니다. (그것을 여기에 있다고 말하는 것이 아니라, 단지 유용한 구별 기능을 만들기 위해 그것을 사용하는 것이다.) 그래, 대부분은 API의 추상화 수준을 훨씬 상회한다. SimonTrew (대화) 2009년 4월 20일 17:41, (UTC)[]

BTW 나는 COM을 API, 프로토콜(진짜 프로토콜이 아니다) 또는 다른 것으로 생각해야 하는지 궁금했지만, 균형적으로 COM(및 Java 등)에서 정의한 물질의 양이 아니라면 100% 엄격한 정의로 API로 적합하다고 생각한다. SimonTrew (대화) 17:44, 2009년 4월 20일 (UTC)[]

나는 웹 API를 설명하는 짧은 섹션(편집 및 추가 참조를 약간 사용할 수 있음)을 추가했는데, 이 구절이 API로 기술하는 기술적 정확성이 어떻든 간에 이제 일반적인 용어가 되었기 때문이다. 단자 (토크) 07:50, 2009년 7월 20일 (UTC)[]

API는 단순히 웹 API가 그 당시에 존재하지 않았다는 이유만으로 원래 웹 API를 지칭한 것은 아니다. 애초에 결코 경직된 정의를 의도하지 않았던 용어의 의미에 대해 현학적이고 트집을 잡는 것은 불합리하다. 구글 자체에서 자체 지도 서비스를 API라고 부르는데, 구글의 사람들이 컴퓨터 용어를 이해하지 못한다고 말할 것인가? 림보 소크라테스 (토크) 22:22, 2009년 10월 22일 (UTC)[]

API는 인터페이스일 뿐이다. 웹 서비스는 정식 계약을 정의한다(SOAP의 경우 WSDL, REST는 Open API도 존재하지만 자체 기술하는 것을 의미한다). 그것은 API의 I 부분을 다룬다. COM에서 우리는 비슷한 것을 본다; I 파트는 처리된다. 응용 프로그램 프로그래밍 부분에 초점을 맞추십시오. WSDL을 사용하면 클라이언트 스텁(및 서버 골격)을 생성할 수 있다. 대부분의 IDL 기반 체계는 이러한 방식으로 작동하므로 RPC, CORBA, DCOM 및 SOAP/WSDL이 해당 범주에 속한다. 생성된 코드는 본질적으로 당신의 API이다. 코드가 없으면 프로토콜만 있을 뿐이지 모든 DB 공급업체는 데이터베이스 드라이버가 데이터베이스와 통신하는 데 사용하는 프로토콜을 가지고 있다는 점을 고려하십시오. 만약 우리가 그 프로토콜을 직접 사용한다면, (가능하다면) API를 사용하는가? 아니, 당연히 아니지 RESTFul 웹 서비스는? 인터페이스는 HTTP + 리소스 형식으로 정의된다. 오픈을 할 수도 있다.API 설명. 리소스 형식이 JSON인 경우 JavaScript 플랫폼에서 생성된 클라이언트 코드 없이 웹 서비스를 사용할 수 있으며, 모든 운영이 표준화(GET, PUT 등)되어 있으며, 따라서 플랫폼이 지원하는 HTTP 클라이언트가 대부분 *is*를 지원함. 또는 그렇게 논쟁된다. 그러나 이것은 HTTP(프로토콜) 의미론에 단순히 지연되는 서투른 API를 만든다. 만약 당신의 주제가 복잡하다면, 당신은 프로그래머로부터 떨어져서 "웹 api"의 모든 HTTP ness를 차단하는 클라이언트-api를 쓰고 싶은 유혹을 받을 수 있다. 72.142.11.38 (토크) 15:45, 2017년 6월 13일 (UTC)[]

아직도 이해가 안가.

여기는 늦어서 그런지 나만 그런 건지도 모르지만, 나는 기사를 읽었는데 아직도 API가 무엇인지, 혹은 그것이 어떤 실제 기능에 사용될 것인지 잘 모르겠어. 그리고 나는 바보 같은 사람이나 컴퓨터에 대해 전혀 모르는 사람이 아니야. 사람들은 흔히 트위터와 연계하여 약어를 사용하는데, API 제한 등에 대해 이야기하는 것을 들은 적이 있다. 위의 누군가가 그것이 너무 기술적인 것이라고 제안했고 나는 그들이 옳을지도 모른다고 생각한다. 자고 나면 내일 다시 와서 다시 읽어보고 머리를 좀 더 잘 수 있는지 알아볼게. 그동안 이런 기사를 일반 조나 조안나에게 좀 더 쉽게 접근할 수 있게 만드는 데 전문지식이 있다면, 조금 다시 쓴 것을 보는 것이 유용할 것 같소? 91.107.207.207 (대화) 23:27, 2009년 4월 24일 (UTC)[]

본기사를 대충 훑어보았는데, 전체는 1980년대 컴퓨터가 아닌 현대 컴퓨터를 가진 사람들만을 위한 것으로 보인다. 그들은 조립자가 소스 코드를 처리할 때 읽어 들이는 심볼 라벨의 표와 객체 코드를 추론하는 것에 대해 이야기하고 있는가? Dexter Nextnumber (talk) 04:02, 2009년 12월 21일 (UTC)[]

제안된 첫 번째 단락

첫 번째 단락의 재작업을 제안한다.

컴퓨터 과학에서 응용 프로그램 프로그래밍 인터페이스(API)는 응용 프로그램이 서비스를 제공하는 라이브러리 및/또는 운영 체제로부터 서비스를 요청하는 방법을 정의하는 인터페이스의 표준 규격이다. 그것은 요청 소프트웨어와 서비스를 제공하는 소프트웨어 사이의 통신에 사용되는 루틴, 데이터 구조, 객체 클래스 및 프로토콜에 대한 규격을 포함할 수 있다. Davemck (대화) 2009년 6월 20일 18:48, (UTC)[]

API - 프로토콜 관계

API와 프로토콜이 어떻게 서로 연관되어 있는지에 대한 기사의 논의는 혼란스럽고 불완전해 보인다. "API도 프로토콜의 구현이 될 수 있다", "API는 직접 사용할 수 있는 라이브러리를 제공한다", "API는 특정 기술에 특유하다"와 같은 문장은 불분명하고, 대부분 부정확하며, 심지어 부정확할 수도 있다. 내 의견으로는 다음과 같은 것이 확실하다.

1) API와 프로토콜의 관계가 있음

2) 이 관계는 설명하는데 중요하다.

2.1) 로컬(처리 중)과 원격 API의 차이점

2.2) 다른 프로그래밍 언어 및 환경에서 동일한 서비스 또는 기능에 액세스할 수 있는 API 간의 차이점

2.3) SOAP 기반 및 REST 기반 웹 API의 차이점(동일한 기능에 대한 액세스 제공)

2.4) 언어 바인딩의 정확한 역할

2.5) 명시적 또는 자동 생성된 언어 바인딩 없이 문서 형태로만 존재하는 추상 인터페이스

나는 이 글에 위의 요점에 대한 만족스러운 토론이 포함되어 있지 않다고 생각한다.

문제의 일부는 이전에 여기에서 논의되었으며 API의 "넓은" 대 "좁은" 정의와 관련이 있다. "넓은" 정의는 서비스나 기능에 대한 프로그램적 액세스를 제공하는 모든 인터페이스를 포함한다. "좁은" 정의는 주어진 프로그래밍 언어, 환경 또는 기술의 맥락에서 API를 엄격하게 고려한다. 기사는 "넓은" 정의를 "...특히 소프트웨어 프로그램이 서로 통신하기 위해 따를 수 있는 규칙과 규격의 집합"으로 시작하지만, 프로토콜에 관한 부분은 "좁은" 관점을 취함으로써 주제를 다룬다. 이 모순은 매우 혼란스럽다.

상대적으로 주제에 대한 이해도가 높지만 위키피디아는 처음이고 참고문헌도 없어 기사 편집이 조금 망설여진다. 주제를 명확히 하기 위해 나와 함께 일하는 데 관심 있는 사람 있어?

--Fmihaly (대화) 2011년 6월 29일 23:39 (UTC)Ferenc[]

너의 제안에 감사하고, 나는 그것이 프로토콜의 차이를 개선할 것이라고 생각한다. 그런 변화를 너 혼자서 얼마든지 만들어라. 위키피디아는 위키이기 때문에 누구나 맨 위에 있는 이 페이지 편집 링크를 따라가기만 하면 거의 모든 기사를 편집할 수 있다.

위키백과 커뮤니티는 당신이 페이지를 업데이트하는데 대담해지도록 장려한다. 솔직한 실수를 저지르는 것에 대해 너무 걱정하지 마. 그것들은 빨리 발견되고 고쳐질 가능성이 높으며, 다른 편집자들은 페이지 기록을 따라가 변화를 보고 그들의 의견을 덧붙일 수 있어. 편집 방법이 확실하지 않으면 페이지 편집 방법을 확인하거나 샌드박스를 사용하여 편집 스킬을 시도해 보십시오. 새로운 기고자는 언제든지 환영한다. 디에고 모야 (대화) 09:56, 2011년 6월 30일 (UTC)[]

유창한 API 설명이 제거됨

유창한 API에서 누가 그 부분을 삭제했는지 궁금하다:이 페이지의 "고급 설명" 부분을 오랫동안 단계별로 편집하고 있는데, 그 부분은 내가 개발하려고 했던 부분이었다. 그렇다면 왜 제거되었을까? — 62.77.56.17 (대화) 14:39, 2011년 11월 25일 (UTC)[]이(가) 추가된 이전의 부호 없는 의견

대리담화 제안

아마도 매셔리, API 액슬(내 프로젝트), 에이피지, 3스케일 같은 API 프록시의 존재에 대해 언급할 만한 가치가 있는가? — 81.151.214.141 (대화) 21:27, 2012년 1월 23일 (UTC)[]이(가) 추가된 이전의 부호 없는 의견

API의 저작권이 없음

「Orace v. Google」 소송 ([2] --Aliuken (토크) 14:40, 2012년 6월 1일 (UTC)[]에서 예측에 따른 API의 저작권 불가에 관한 섹션이 있어야 한다고 생각한다.

Apple 참조

나는 "애플 주식회사"라는 보석이 있다고 믿는다. 호환성을 깨거나 더 느린 "에뮬레이션 모드"에서 API를 구현하는 등의 우려를 덜었다. 이는 이전 소프트웨어를 쓸모없게 만드는 비용에서 개발의 자유를 더 많이 허용한다."가 마이크로소프트에 치우친 것으로 간주됨에 따라 제거되어야 한다(또는 최소한 다시 쓰여져야 한다). 또한, 이 진술을 뒷받침하기 위해 어떠한 인용문도 제공되지 않고 있으며, 나는 그러한 참고문헌을 찾는 데 성공하지 못했다.

Mfd24 (대화) 04:47, 2012년 10월 19일 (UTC)[]

도지 단면

이 편집으로 "사용 언어" 섹션이 삭제된 점에 유의하십시오. 같은 편집자에 의한 다음 편집은 이것이기 때문에 나는 이것이 공공 기물 파손이라는 인상을 받는다. 하지만 이 구간은 요점을 놓친 것으로 보인다. 모든 API가 언어에 독립적이지 않은가? 그 구역은 출처가 없었다.

우리가 기피 섹션에 대해 다루고 있는 동안, "Documentation" 섹션은 API의 문서화가 아닌 일반적인 코드 문서화에 관한 것으로 보인다. 이 편집은 대부분 62.77.56.17 (토크 · 기여 · 카운트 · 로그)에 의해 이루어진다.

Yaris678 (대화) 16:43, 2012년 10월 23일 (UTC)[]

API에 대한 기타 정보(비기술적)

이 기사는 API가 무엇인지에 초점을 맞추고 있다. 하지만 나는 또한 추가적인 정보를 보고 싶다 - 이 기사를 보라 - http://venturebeat.com/2013/07/31/enterprise-api-programs/ 산업에서 API가 사용되는 방법, 다른 회사 및 기관에서 사용되는 방법, 그리고 그것들에 대한 일반적인 통계에 대한 정보를 가지고 있는 사람? — 192.55.54.41 (대화) 16:20, 2013년 7월 31일 (UTC)[]이(가) 추가된 이전의 부호 없는 의견

셀프레프 해트노트

방금 http://en.wikipedia.org/w/api.php,에 {{selfref}}개의 해트노트를 추가했는데 존블랙버른에 의해 되돌아온 것이기 때문에 이 내용을 오픈하여 토론하고자 한다. 몇몇 사람들이 우리의 API를 찾으러 온다고 가정하는 것은 그렇게 불합리하지 않다고 생각한다. 소프트 리디렉션 api.php에 대한 트래픽 통계를 참조하십시오. 셀프레프의 요점은 사용자가 내부 위키백과 페이지를 상당히 찾고 있을 가능성이 높은 드문 경우를 위한 것인데, 나는 이것이 그러한 경우라고 생각한다. 내 의견으로는, 링크가 /wiki 섹션에 위치한 것이 아니라 위키백과 링크이기 때문에, 기술적으로 말하면, 외부라는 것은 차이가 없다. — PinkAmpers&^{(Je vous invite à me parler)} 01:11, 2013년 8월 3일 (UTC)[]

그것에 대한 나의 생각은 두 가지였다. 첫째로, 어떤 종류의 외부 연결도 할 수 있는 곳이 아니다. 이러한 연결은 일반적으로 외부 링크에 연결되며, 단, 공식 링크와 같은 좁은 예외는 제외된다.

인포박스 만약 그것이 실제 페이지와의 링크였다면 그것은 기사가 아니라 프로젝트 페이지일 뿐이고 그것들 또한 대개 기사로 링크되어서는 안 된다. WP가 운영하는 소프트웨어에 관심이 있는 사람들은 또한 기술적인 측면을 포함한 소프트웨어에 대해 더 많이 알기 위해 사이드바에 있는 About Wikipedia 링크나 모든 페이지의 맨 아래에 있는 Mediawiki 링크와 같은 링크도 사용할 수 있다. 통계는 하루에 150개인데, 이 페이지는 하루에 6,000개의 조회수 중 약 2.5%를 차지한다. 해트노트는 독자가 관심을 가질 것 같은 기사를 뜻하는데, 기사라고 해도 보기 힘든 견해는 2.5%에 불과하다. 마지막으로 WP의 API 문서를 읽는데 진정으로 관심이 있는 사람은 스스로 찾는데 어려움이 없어야 한다.--JohnBlackburne^words_deeds 01:42, 2013년 8월 3일 (UTC)[]

외부 링크 수정

안녕하십니까, 위키백과 여러분.

나는 방금 애플리케이션 프로그래밍 인터페이스의 외부 링크 하나를 수정했다. 잠시 시간을 내어 내 편집을 검토하십시오. 질문이 있거나 봇이 링크 또는 페이지를 모두 무시해야 하는 경우, 추가 정보를 보려면 이 간단한 FaQ를 방문하십시오. 나는 다음과 같이 변경했다.

• http://www.microsoft.com/windowsxp/using/helpandsupport/learnmore/appcompat.mspx에 아카이브 https://web.archive.org/web/20090926235439/http://www.microsoft.com:80/windowsxp/using/helpandsupport/learnmore/appcompat.mspx 추가

변경 내용 검토를 마쳤으면 아래 선택된 매개 변수를 true로 설정하거나 다른 사용자에게 알리지 못함(문서: {{Sourcecheck}}).

Y 편집자는 이 편집을 검토하고 발견된 오류를 수정했다.

• 봇에 의해 잘못 죽은 것으로 간주된 URL을 발견한 경우, 이 도구로 해당 URL을 보고할 수 있다.
• 보관 파일 또는 URL 자체에서 오류를 발견한 경우 이 도구로 오류를 수정할 수 있다.

건배.—InternetArchiveBot (Report bug) 16:08, 2016년 10월 16일 (UTC)[]

확인. --Wikiinger (대화) 23:17, 2017년 2월 20일 (UTC)[]

끊어진 고리

안녕, 관리자.

나는 이 페이지의 Application programming interface에 있는 내용을 읽고 있었는데, 연결이 끊어진 것을 발견했다. 그것은 "시스템들을 모듈로 분해하는 데 사용될 기준에 대하여"라는 앵커 텍스트가 있는 pdf 파일이다. 가까스로 원본 pdf 파일을 찾아냈다.여기 저 파일의 링크가 있다. https://web.archive.org/web/20180108050207/http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf. 독자들이 원본 pdf 파일을 읽을 수 있도록 pdf를 이 링크에 연결해줄 것을 요청하겠다.그것 외에도 나는 또한 이 웹사이트 techved.com이 애플리케이션 프로그래밍 인터페이스에 많은 기여를 한다는 것을 알게 되었다. 이 웹사이트에서 정보를 보고 싶다.

API 예?

나는 작은 API를 추가하는 것이 이해하는데 도움이 될 것이라고 생각한다. 예를 들어 설명문을 읽어보면 인터페이스가 대부분 함수 호출로 구성되어 있다는 어떤 것도 나에게서 튀어나오지 않는다. 당신은 어떻게 생각하나요? 다니엘카르데나스 (토크) 19:17, 2019년 12월 12일 (UTC)[]

이에 동의한다. --Marc.2377 (대화)04:04, 2019년 12월 14일 (UTC)[]

API의 역사가 나무의 숲을 그리워한다고 생각하는 사람이 있는가?

나는 1971년부터 프로그래밍을 해왔고, 현재 소위 "웹 API"라고 불리는 것은 2000년까지도 API로 간주되지 않을 것이다. 분명히 누군가가 일방적으로 용어를 재정립한 논문을 발표했고, 10년 내지 20년 후에 검색에 뜬다. 왜냐하면 오래된 것은 인터넷과 vaila, API라는 용어는 완전히 재정립되어 있기 때문이다. 이 글에서 API의 역사는 엉터리 장학금 냄새가 난다. 만일 어떤 이상한 이유로 업계가 조정된 서비스 집합[당기의 의미인 것]을 노출하기 위해 웹 엔드포인트 집합의 개념에 실제로 맞지 않는 용어를 공동 선택할 필요가 있다고 본다면, 그렇게 될 것이다, 그러나 위키백과 기사는 적어도 현재 용어가 이해되었던 것과 전혀 다르다는 기록 해협을 설정해야 한다.y 용어의 기원자. 또한, AFAICT는 2000년 이전에 언급된 어떠한 언급도 없으며, 그 자체로 이 글의 장학금은 형편없다는 엄청난 팁이 되어야 한다. 나는 적어도 1989년까지 그 용어를 사용하게 된 것을 기억할 수 있고, 나는 그것이 훨씬 더 오래되었다고 의심한다. 구글 책에 실린 잡지를 빠르고 지저분한 검색만 해도 1989년 이미 잘 알려져 있고 이해된 용어인 것처럼 사용되었던 참고문헌들이 되돌아온다. 다시 말하지만, 이 글의 장학금은 형편없다. — Gkochanowsky가 추가한 선행 미서명 논평 (대화 • 기여) 18:10, 2020년 3월 2일 (UTC)[]

Gkochanowsky, 당신은 API라는 용어를 다시 정의했다고 말하는 논문의 이름이나 링크를 가지고 있는가?Jno.skinner (토크) 03:39, 2020년 9월 17일 (UTC)[]

Jno.skinner, 만약 당신이 실제 연구자였다면, 당신이 나에게 참고자료를 달라고 도전하지 않았다면, 당신은 직접 가서 그것을 찾았을 것이다. 왜 날 믿어?

https://www.ics.uci.edu/~fielding/pubs/pubs/top.htm—Gkochanowsky(토크 • 기여) 20:07, 2021년 7월 15일(UTC)[]이(가)에 서명되지 않은 코멘트가 추가되기 전.

WP:BURDEN, 만약 당신이 클레임을 제기한다면, 당신이 소스를 통해 그것을 뒷받침해야 한다. 어쨌든 이 기사에서는 API의 개념이 처음에는 웹 API를 포함하지 않았다고 언급하고 있으며, 당신이 링크한 기사도 히스토리 섹션에 언급되어 있다. 물론 그렇긴 하지만, "웹 API"라는 용어가 2000년 이후부터 사용되기 시작했다면 언급할 가치가 있을 것이다. -조크 반 히스 (대화) 12:07, 2021년 7월 16일 (UTC)[]

요청된 이동 2020년 8월 3일

다시 열었음 및 다시 시작됨

웹 API가 원격 API임

API를 운영 체제, 원격 API, 웹 API로 분류하는 것은 나를 혼란스럽게 한다. 이 절에서 인용된 출처 중 어느 것도 명확하게 이 정의를 내리지 않는다.

높은 수준에서, 나는 API가 로컬과 원격의 두 가지 주요 범주로 구분된다고 주장한다. 이 결정은 클라이언트가 인터페이스와 상호작용하는 위치와 인터페이스가 시행되는 위치에 따라 달라진다.

애플리케이션이 프로그래밍 언어로 Collections API, 하드웨어 API 또는 데이터베이스 드라이버와 같은 로컬 인터페이스와 상호 작용할 때 일반적으로 클라이언트 내에서 코드를 통해 인터페이스를 시행한다. 이는 기본 인터페이스를 포함하고 컴파일 시간에 실패하거나 해석 언어로 번역된 통역관의 실패를 통해 이루어질 수 있다. 인용된 JDBC의 예에서 클라이언트는 진행 중인 인터페이스/API와 상호작용을 하고 있는데, 그러한 상호작용으로 인해 잠재적으로 원격 시스템에 대한 호출이 발생하더라도, 인터페이스와의 상호작용이 계약이 시행되는 현지에서 발생한다. JDBC API 뒤에 있는 구현에 의해 이루어지는 원격 호출은 잘못된 쿼리, 연결 정보 등으로 인해 실패할 수 있지만, API는 그 안에 명시된 예외를 감안하여 여전히 계약을 준수할 것이다. 나는 이 주장을 이용하여 JDBC가 로컬 API라고 주장할 것이다.

원격 API를 사용할 때 클라이언트는 프로세스에서 인터페이스를 적용하도록 보장되지 않으며 API의 동작은 클라이언트에서 프로그램적인 의미로 엄격하게 정의되지 않는다. API의 계약은 클라이언트의 애플리케이션 코드에 대해 외부로 강제되며 API 인터페이스에 지정된 동작은 클라이언트에서 프로그래밍 방식으로 강제될 수 없다. 클라이언트는 단순히 프로그래머의 원격 API에 관한 정보 해석에 따라 메시지를 포맷하여, 원격 API가 계약 준수를 결정하고 (잠재적으로) 메시지를 처리하는 지점으로 프로토콜을 통해 전달하고 있다. 원격 API의 명확한 지표는 클라이언트가 API를 호출하기 위해 사용하는 프로세스 외부에서 상호작용이 발생하기 때문에 클라이언트의 언어에 구애받지 않는다는 것이다. — Kmb385 (대화 • 기여) 10:37, 2020년 12월 6일 (UTC)[]에 의해 추가된 사전 서명되지 않은 코멘트

방대한 범위의 역사적, 문화적 유물로서의 API

나는 드라이브 바이 에디터인데, 처음 접했을 때 한 페이지를 치고 부족함을 발견하고는, 다시 돌아오지 않을 것 같은 활기차게 움직인다. 나는 내 작품의 어떤 부분이 곧 얼버무리는 다른 편집자의 취향에 맞지 않는다면 재빨리 되돌아간다는 것을 받아들이는 것을 배웠다.

기록을 위해, 내 시도된 리드 익스텐션은 다음 위치에 보존된다.

• API

나는 API가 CS 전공자의 손에 전적으로 그 설명을 맡기기에는 너무 인간적으로 중요하다고 강하게 믿는다. — MaxEnt 18:10, 2021년 3월 2일 (UTC)[]

나는 당신이 말한 것처럼 그 주제가 엄청난 범위의 문화적 유물이라는 것에 전적으로 동의한다. 그러나 납은 이제 신체에 소싱되거나 설명되지 않은 진술들을 포함하고 있으며, 아마도 너무 길다. 그래서 나는 그것의 많은 부분이 살아남지 못할까 봐 두려워. Jno.skinner (대화) 18:53, 2021년 3월 2일 (UTC)[]

랩 음악

나는 다음 두 구절을 추가하기 위해 돌아왔다.

OS 내부 진화에 관한 사항:

점차 MIDI 인터페이스를 갖춘 악기, 1980년대 게임 컨트롤러, 1990년대 USB 주변기기 등의 사용자 기기들이 운영체제 자체 내부의 중요한 API 계층인 운영체제 기기 드라이버에 의해 추상화되었다.

나는 그때 거기에 있었다. 크리에이티브들이 이 쇼를 진행하는 것은 항상 부분적인 경우였고, 이 경우는 더우르 회색곰팡이들에게 불편한 증식 압력을 많이 가했다.

마지막 단락, 두 가지 관점에 관한 사항:

어떤 맥락에서 "응용프로그램"은 최종 사용자 응용프로그램을 좁게 언급하지만, 소프트웨어 개발자들에게 스택의 각 계층은 아래의 계층과 관련된 "응용프로그램"이며, 따라서 두 계층이나 구성요소가 접촉하는 곳마다 산업 내에서 "API"라는 용어가 발생한다.

— MaxEnt 19:01, 2021년 3월 2일 (UTC)[]

API로서의 데이터

잠깐 들락날락하기에는 너무 많다.

API의 개념은 하드웨어와 코드에 국한되지 않는다. 2001년 Tim Berners-Lee가 도입한 시맨틱 웹은 네트워크 프로그래밍을 시스템의 행동보다는 기반 데이터 자체를 감싸는 API로 취급하는 제안으로, 지능형 에이전트의 진화를 개방형 혁신 기업가정신 생태계로서 바라보는 관점이었다. 대신 우리는 현재 아마존 알렉사와 시리 같은 독점 대리점을 가지고 있는데, 이 대리점들은 프로그래밍 방식 API가 아닌 자연 언어 사용자 인터페이스를 제공하는데, 이것은 휴먼 인터페이스 경계선에 대한 완전히 다른 엔지니어링 자세다.

어쩌면 이쯤에서 내가 리드를 조금 더 늘렸는지도 모른다.

만약 영혼이 너를 움직인다면, 너의 장화를 가지런히 채워라. — MaxEnt 19:18, 2021년 3월 2일 (UTC)[]