Skip to content

Interfaz de Programación de Aplicaciones

Una interfaz de programación de aplicaciones (API, por sus siglas en inglés) es una forma en que dos o más programas informáticos se comunican entre sí. Es un tipo de interfaz de software que ofrece servicios a otras piezas de software. Un documento o estándar que describe cómo construir o usar dicha conexión se denomina especificación de API; se dice que un sistema informático que cumple el estándar implementa o expone una API.

Distinción de las interfaces de usuario

Una API se distingue de una interfaz de usuario por su consumidor previsto: una interfaz de usuario conecta al usuario humano con el sistema; una API conecta programas de software entre sí. Una API no está destinada a ser utilizada directamente por una persona sino por un programador que la incorpora en un software más grande. Las llamadas que componen una API se conocen como subrutinas, métodos, solicitudes o puntos de conexión, dependiendo del estilo arquitectónico.

Historia

Orígenes en bibliotecas de subrutinas

Años 1940–1950. La base conceptual de la API fue establecida por los científicos informáticos británicos Maurice Wilkes y David Wheeler en su trabajo desarrollando una biblioteca de software modular para EDSAC, un ordenador primitivo, en la década de 1940. Su libro de 1951 The Preparation of Programs for an Electronic Digital Computer contiene la primera especificación de API publicada.

Años 1960–1970. El término "application program interface" (interfaz de programa de aplicación) apareció por primera vez en un artículo de 1968 titulado Data structures and techniques for remote computer graphics, presentado en una conferencia de la Association for Information Processing Societies (AFIPS). El término fue introducido en el campo de las bases de datos por C.J. Date en un artículo de 1974; se convirtió en parte del marco ANSI/SPARC para sistemas de gestión de bases de datos.

Auge de las API remotas y web

Años 1990. Para 1990, la API era definida por el tecnólogo Carl Malamud simplemente como "un conjunto de servicios disponibles para un programador para realizar ciertas tareas". El concepto se amplió con el surgimiento de las llamadas a procedimientos remotos y las API web. En la década de 1990, con la difusión de internet, estándares como CORBA, COM y DCOM compitieron para convertirse en el mecanismo dominante para exponer servicios API a través de redes.

Años 2000 hasta el presente. La disertación de Roy Fielding de 2000 en la Universidad de California en Irvine definió la Transferencia de Estado Representacional (REST) y describió la idea de una "interfaz de programación de aplicaciones basada en red". Las API web XML y JSON vieron una adopción comercial generalizada a partir del año 2000. La reciente proliferación de arquitecturas de microservicios ha convertido el diseño de API en un aspecto central de la arquitectura de software empresarial.

Tipos

Interfaces locales — bibliotecas y sistemas operativos

API de bibliotecas. La interfaz de una biblioteca de software es un tipo de API. La API describe y prescribe el "comportamiento esperado" (especificación) mientras que la biblioteca es una "implementación real" de ese conjunto de reglas. Una única API puede tener múltiples implementaciones.

API de sistemas operativos. POSIX, por ejemplo, proporciona un conjunto de especificaciones de API comunes diseñadas para permitir que las aplicaciones escritas para un SO compatible con POSIX se compilen para otro. Linux y la Berkeley Software Distribution (BSD) implementan ambos las API POSIX.

Interfaces en red — API remotas y web

API remotas. Las API remotas permiten a los desarrolladores manipular recursos remotos a través de protocolos — estándares específicos para la comunicación que permiten que diferentes tecnologías funcionen juntas independientemente del lenguaje o plataforma.

API web. Las API web son servicios a los que acceden los dispositivos cliente a un servidor web usando el Protocolo de Transferencia de Hipertexto (HTTP). Los dispositivos cliente envían una solicitud en forma de solicitud HTTP y reciben un mensaje de respuesta típicamente en formato JSON o XML.

Políticas de publicación

Las API se clasifican típicamente por su política de acceso: las API privadas son solo para uso interno de la empresa; las API de socio están disponibles solo para socios comerciales específicos bajo acuerdo contractual; las API públicas están disponibles para uso general del público, sujetas a autenticación y límites de velocidad.


citas: user-interface-design, user-experience-design, fog-computing, edge-computing

Important Information

Important Information

Corporate structure. PointSav Digital Systems ("PointSav") is a trade name of Woodfine Capital Projects Inc. ("Woodfine"). PointSav does not itself offer, sell, or solicit any security. Any securities offering associated with Woodfine's real-property direct-hold solutions is made exclusively by Woodfine, and only by means of the applicable Private Placement Memorandum.

No investment advice. This wiki's content is provided for engineering, operational, research, and development purposes. Nothing on this wiki constitutes investment advice or a solicitation to invest in any Woodfine partnership or direct-hold solution.

Intellectual property. The PointSav name, trade name, wordmark, and marks, together with all current and future PointSav- and Totebox-branded products, services, and offerings — and the software, source code, documentation, design system, and all related materials — are proprietary to Woodfine and its affiliates, except for components identified as open source. No rights are granted except as expressly set out in a written license or agreement. See TRADEMARK.md in this repository for the full trademark notice.

Open source components. Portions of the platform are made available under permissive open-source licenses identified in the accompanying repository. Use of those components is governed by their respective license terms.

No warranty; informational use. Content on this wiki is provided for general informational purposes only and does not constitute a representation, warranty, or commitment with respect to product functionality, availability, pricing, or roadmap. Some articles describe planned or intended features, capabilities, and milestones — language such as "planned," "intended," "targeted," "may," and "expected" marks this forward-looking content, which is subject to change and does not constitute a commitment regarding future performance.

Confidentiality. Where an article describes an operational or deployment detail that is not intended for public disclosure, that article is not published on this wiki. Content here is general-purpose engineering documentation, not customer-specific configuration.

Jurisdiction. Woodfine Capital Projects Inc. is organized in British Columbia, Canada. References to the Sovereign Data Foundation on this wiki describe a planned or intended initiative only, not a current equity holder or active governance body.

Changes to this notice. PointSav may update this notice from time to time; the version posted on this page governs.

Not a filing system. This wiki is not a securities filing system, an electronic disclosure repository, or a substitute for SEDAR+ or any other regulatory filing system. Formal securities filings are made through the applicable regulatory filing system, not through this wiki.

Full disclaimer. This notice supplements, and does not replace, the full Disclaimers article. In the event of any conflict, the full Disclaimers article governs.

Read the full disclaimer →