Definición: Una interfaz de programación de aplicaciones (API) es una descripción de un método que permite que una pieza de software se comunique con otro programa para obtener un servicio. Este servicio puede proporcionar acceso a datos o realizar una función específica. Las interfaces están diseñadas para la mayoría del software empresarial y desempeñan un papel fundamental en los sistemas operativos que controlan la mayoría de las funciones informáticas básicas.
A menudo tenemos que recurrir a otras personas para pedirles que realicen un trabajo que no podemos hacer solos por una razón u otra, por ejemplo, abrir una caja de depósito en un banco. Asimismo, casi todo el software requiere el uso de otros programas para realizar determinadas funciones. Para ello se utiliza un conjunto de solicitudes estandarizadas (llamadas interfaces de programación de aplicaciones), definidas para el programa al que se dirige la solicitud. Casi todas las aplicaciones acceden a la API del sistema operativo subyacente para realizar funciones básicas como el acceso al sistema de archivos.
Esencialmente, la interfaz de aplicación de un programa define la forma correcta que un desarrollador puede utilizar para llamar a los servicios que necesita un programa en particular. Los desarrolladores pueden ejecutar consultas agregando llamadas al código de su aplicación. La sintaxis se describe en la documentación de la aplicación llamada.
Al proporcionar un medio para solicitar servicios de software, una API garantiza el acceso o la capacidad de abrir una aplicación. Según Josh Walker, analista de Forrester Research, “Crear una aplicación sin una API es como construir una casa sin puertas. Para cualquier tarea informática, una interfaz de programación de aplicaciones abre ventanas y puertas para el intercambio de información”.
Además, las interfaces de programación de aplicaciones permiten que las aplicaciones se comuniquen entre sí. Las aplicaciones empresariales de SAP incluyen una API llamada BAPI que permite que otras aplicaciones accedan a datos comerciales. Cuando se adopta un estándar industrial para datos, generalmente sigue con una única interfaz de programación de aplicaciones que proporciona acceso a las aplicaciones que procesan esos datos.
El middleware actúa como una API análoga y estandarizada que permite que las aplicaciones escritas para diferentes plataformas o en diferentes idiomas se comuniquen.
Según Adam Braunstein, analista de Robert Frances Group, aunque las API proporcionan servicios rápidos y manera conveniente acceso a una aplicación, pueden ser demasiado limitados para los usuarios que requieren capacidades más avanzadas, particularmente los ISV. El software gratuito permite obtener el texto de cualquier comando y operación en la aplicación y así brindar mayor flexibilidad. Pero puede llevar demasiado tiempo comprender el texto fuente y, además, este enfoque inevitablemente plantea dudas sobre la propiedad intelectual del autor.
Cuando Novell anunció el año pasado que pondría el código fuente de su software Novell Directory Services (NDS) a disposición del público en general, Chris Stone, entonces vicepresidente de Novell, dijo que la mayoría de los desarrolladores empresariales se mostraban reacios a profundizar en el código libremente. software distribuido. De hecho, afirma, los desarrolladores quieren conjuntos adicionales de API que les ayuden a trabajar más rápido. Y hasta el día de hoy los textos originales de NDS no se han publicado.
Los desarrolladores empresariales deben decidir si incluyen interfaces de aplicaciones en las aplicaciones que crean. Con el tiempo, la probabilidad de que otro desarrollador necesite acceder a los servicios de esta aplicación solo aumenta. Según Brownstein, creación de API aliviará a los programadores que posteriormente trabajarán con esta aplicación de la necesidad de buscar el texto requerido y comprender cómo funciona el código.
Las interfaces de programación de aplicaciones son fáciles de crear, pero como señaló Larry Perlstein, analista de GartnerGroup, pueden ser difíciles de aprender. Los desarrolladores y fabricantes de aplicaciones deben pensar constantemente si sus interfaces de programación de aplicaciones serán comprensibles para los desarrolladores posteriores. "Una API es inútil a menos que esté documentada", afirmó Perlstein, aunque algunos proveedores dejan sus API sin documentar.
Si una empresa quiere frustrar a los desarrolladores, puede mantener sus API en secreto o cambiarlas rápidamente. Muchos de los críticos de Microsoft, incluidos fiscales gubernamentales y competidores, acusan a la empresa de no rehuir tales prácticas.
Andrew Shulman describió varias API del sistema operativo ocultas sistemas windows en su libro "Windows indocumentadas". Ahora trabaja como consultor para Caldera, que está demandando a Microsoft por violar las leyes antimonopolio. Ahora, en lugar de ocultar las API, Shulman escribe: “Windows tiene una arquitectura de fregadero que permite ocultar nuevas interfaces de programación de aplicaciones. ¿Esto? La API es un intento de evitar que Windows sea clonado".
El juez Thomas Penfield Jackson presentó argumentos similares en una audiencia del 5 de noviembre en el caso DOJ v. microsoft. Dijo que "intentar clonar la API de Windows de 32 bits es tan costoso e inútil que hace casi imposible que surja un competidor de Windows".
Pero Perlstein señaló que al criticar a la empresa por sus métodos de soporte de la API de Windows, los competidores de Microsoft están dando rienda suelta a su envidia a expensas de la justicia. El portavoz de Microsoft, Jim Cullinan, dice que Microsoft está constantemente mejorando Windows y actualizando y agregando interfaces de programación de aplicaciones, ya que desacelerar el ritmo de modernización podría resultar en el incumplimiento de los plazos de lanzamiento.
Las interfaces de programación de aplicaciones (API) tienen una sensación misteriosa y los fabricantes o desarrolladores están ansiosos por agitarlas como varitas mágicas que pueden resolver todos los problemas. Pero, en realidad, las API pueden ser muy simples y poderosas. Cada uno de nosotros utilizamos algo parecido a una API en la vida cotidiana cuando, por ejemplo, le pedimos a alguien un servicio. Las API ofrecen menos flexibilidad que el código disponible gratuitamente, pero más flexibilidad que las aplicaciones completamente propietarias.
Imagina que tienes tres vecinos. Cerrado Zinovy, Abierto Oscar y API Ann. Cada uno de ellos es un análogo de una aplicación. Como cualquiera de tus vecinos, a veces necesitas pedirles prestado algo, como una cortadora de césped. Este es el equivalente a la integración de aplicaciones.
Cerrado Zinovy simplemente no le proporciona ningún servicio. Corta su propio césped detrás de la alta valla que rodea su casa. No sólo no puedes pedirle nada, sino que ni siquiera puedes entrar a su jardín para intentar hablar porque su cerca no tiene puerta. Una aplicación como Closed Zinovy no proporciona ni código fuente ni una interfaz de programación de aplicaciones.
Óscar abierto- todo lo contrario de él. Es tan abierto que te permite entrar libremente a su jardín cuando quieras e incluso reparar su cortadora de césped, por lo que responde muy bien a tus solicitudes. Por supuesto, una vez que cambies el diseño del cortacésped descrito en el manual, tendrás que encargarte de sus propias reparaciones y mantenimiento. Aplicaciones como Open Oscar son de código abierto, lo que te permite personalizarlas como quieras.
api anna le permitirá usar su cortadora de césped si le pide que lo haga correctamente (llamando a la API "daikomower" en el cuerpo de su aplicación). No puede entrar por la puerta sin dicha solicitud y no puede encender la cortadora de césped y cortar el césped. Pero puedes utilizar este servicio (cortar el césped) cuando quieras. La mayoría de las veces, las empresas utilizan aplicaciones cerradas pero que tienen una API, como Anna.
Leonid Yakubovich 26 de noviembre de 2012 a las 13:59¡Saludos!
En este artículo veremos qué es una API, dónde, cómo y para qué se utiliza. También veremos cómo se puede utilizar la API en sus desarrollos web y cómo puede simplificar la vida de un programador web.
Entonces comencemos con la definición. API (Interfaz de programación de aplicaciones) es una interfaz de programación, una interfaz para crear aplicaciones. En términos más comprensibles, una API es un código listo para hacer la vida de un programador más fácil. La API se creó para que un programador pudiera facilitar la tarea de escribir una aplicación mediante el uso de código ya preparado (por ejemplo, funciones). El conocido jQuery, escrito en JavaScript, también es una especie de API. Si miramos este ejemplo específicamente, jQuery hace que escribir código sea mucho más fácil. Lo que se podría hacer usando herramientas JavaScript normales en 30 líneas está escrito en 5-6 usando jQuery. Si miramos las API en general, podemos encontrar una gran cantidad de servicios que brindan soluciones de desarrollo. El más famoso hoy en día es el servicio code.google.com, que proporciona unas cincuenta API diferentes. Esto incluye una interfaz para crear aplicaciones de Android, varias API para trabajar con AJAX y varias API de aplicaciones que se pueden personalizar fácilmente a su gusto.
Después de todo, ¿tiene sentido escribir código usted mismo? ¿Por qué trabajar sobre lo ya creado? ¿Tiene sentido rechazar soluciones gratuitas (y de hecho, incluso ayuda gratis) en el desarrollo web? Si respondió "NO" a todas estas preguntas, considere que comprende la esencia de la API.
Pero también quiero hacer una reserva. Los desarrolladores principiantes NO deberían utilizar soluciones a medio preparar, ya que no podrán hacer frente al futuro. verdadero desafío. Por lo tanto, si usted web para principiantes programador, entonces no utilice productos semiacabados. Aprenda a pensar con su propia cabeza, cree varios algoritmos para comprender la esencia de la programación. También digo, ya dirigiéndome a todos, que API no es soluciones listas para usar, este es un entorno, una interfaz para crear sus proyectos. No comes chuletas congeladas de la tienda, ¿verdad? Primero los fríes, ¿verdad? Esta analogía capta muy claramente la esencia de la API.
En general, les dije qué es una API, dónde y cómo se usa y, lo más importante, por qué. Diviértete estudiando programación web y comprensión de sus profundidades cada vez mayores!
API de Windows: un conjunto de funciones del sistema operativo
La abreviatura API parece muy misteriosa e incluso aterradora para muchos programadores novatos. De hecho, una interfaz de programación de aplicaciones (API) es sólo un conjunto de funciones ya preparadas que los desarrolladores de aplicaciones pueden utilizar. En general, este concepto es equivalente a lo que antes se llamaba más a menudo biblioteca de subrutinas. Sin embargo, API suele referirse a una categoría especial de dichas bibliotecas.
Durante el desarrollo de casi cualquier aplicación bastante compleja (MyApplication) para el usuario final, se forma un conjunto de funciones internas específicas que se utilizan para implementar este programa en particular, que se denomina API MyApplication. Sin embargo, a menudo resulta que estas funciones pueden utilizarse eficazmente para crear otras aplicaciones, incluso por parte de otros programadores. En este caso, los autores, en función de la estrategia de promoción de su producto, deben decidir la pregunta: ¿abren el acceso a este conjunto a usuarios externos o no? Si la respuesta es sí, la frase "El paquete incluye un conjunto abierto de funciones API" aparece en la descripción del paquete de software como una característica positiva (pero a veces por dinero adicional).
Por lo tanto, la mayoría de las veces una API se refiere a un conjunto de funciones que forman parte de una aplicación, pero que también están disponibles para su uso en otros programas. Por ejemplo, Excel, además de la interfaz de usuario final, tiene un conjunto funciones de excel Una API que se puede utilizar, en particular, al crear aplicaciones utilizando VB.
En consecuencia, la API de Windows es un conjunto de funciones que forma parte del propio sistema operativo y al mismo tiempo es accesible para cualquier otra aplicación, incluidas las escritas en VB. En este sentido, la analogía con el conjunto de interrupciones del sistema BIOS/DOS, que en realidad es una API de DOS, está bastante justificada.
La diferencia es que la gama de funciones API de Windows, por un lado, es mucho más amplia en comparación con DOS y, por otro lado, no incluye muchas de las herramientas para administrar directamente los recursos informáticos que estaban disponibles para los programadores en el pasado. SO. Además, las llamadas a la API de Windows se realizan mediante llamadas a procedimientos ordinarios y las llamadas a funciones de DOS se realizan mediante una instrucción especial del procesador llamada Interrupción.
A pesar de que VB tiene una gran variedad de funciones, en el proceso de desarrollo más o menos serio se descubre que sus capacidades a menudo no son suficientes para resolver los problemas necesarios. Al mismo tiempo, los programadores novatos a menudo comienzan a quejarse de las deficiencias de VB y piensan en cambiar de herramienta, sin sospechar que su computadora tiene un gran conjunto de herramientas y solo necesitan saber cómo usarlas.
Al familiarizarse con la API de Win, se descubre que muchas funciones integradas de VB no son más que llamadas a los procedimientos correspondientes del sistema, pero solo se implementan en forma de sintaxis. de este idioma. Teniendo esto en cuenta, la necesidad de utilizar la API viene determinada por las siguientes opciones:
También se debe enfatizar que algunas funciones API (su participación en Win API es muy pequeña) no se pueden llamar desde programas VB debido a una serie de limitaciones del idioma, por ejemplo, debido a la imposibilidad de trabajar con direcciones de memoria. Pero en algunos casos, las técnicas de programación no triviales pueden ayudar (en particular, en el caso de las mismas direcciones).
El punto de vista personal del autor es el siguiente: en lugar de expandir las funciones integradas de VB de una versión a otra, se debe dar una buena descripción de las funciones API más populares. Al mismo tiempo, me gustaría aconsejar a los desarrolladores que no esperen a que aparezca. nueva versión herramientas con funciones avanzadas y observe más de cerca la composición de la API Win existente; es probable que las capacidades que necesita ya se hayan implementado en la versión VB 1.0, lanzada en 1991.
Esta no es una pregunta tan simple, considerando que el número de funciones API de Win32 se estima en unas 10 mil (nadie conoce la cifra exacta, ni siquiera Microsoft).
VB (versiones 4-6) incluye un archivo que describe las declaraciones de Win API: WIN32API.TXT (le contaremos más sobre su uso más adelante). Pero, en primer lugar, con su ayuda puede obtener información sobre el propósito de una función en particular y sus parámetros solo mediante los nombres mnemónicos utilizados y, en segundo lugar, la lista de funciones en este archivo está lejos de ser completa. En un momento (hace siete años), VB 3.0 tenía archivos de ayuda especiales que describían las funciones de la API Win16. Sin embargo, ya en la versión 4.0 esta información útil con una interfaz conveniente desapareció.
Puede encontrar información completa sobre la API Win32 en la ayuda del kit de desarrollo de software de plataforma, que se incluye en los CD de la biblioteca MSDN incluidos con VB 5.0 y 6.0 Enterprise Edition y Office 2000 Developer Edition. Sin embargo, encontrar allí la información necesaria y comprenderla no es nada fácil. Sin mencionar que todas las descripciones allí se dan en relación con el lenguaje C.
Los libros del famoso experto estadounidense Daniel Appleman son generalmente reconocidos en el mundo por aprender a programar API en el entorno VB. Su Guía del programador Visual Basic de Dan Appleman para la serie API de Windows (para Win16, Win32 y varias versiones de VB) ha sido uno de los libros más vendidos para programadores de VB desde 1993. El libro Guía del programador VB 5.0 de Dan Appleman para la API Win32, publicado en 1997, fue traído al autor desde Estados Unidos por un amigo que lo encontró en la primera librería de una pequeña ciudad de provincias.
Este libro tiene más de 1500 páginas y cubre técnicas generales de programación API en VB, así como más de 900 funciones. El CD incluido contiene el texto completo del libro y todos los ejemplos de programas, así como varios capítulos adicionales no incluidos en la versión impresa. En 1999, Dan Appleman publicó un nuevo libro, Win32 API Puzzle Book and Tutorial for Visual Basic Programmers de Dan Appleman, que incluye información sobre otras 7.600 funciones (aunque no tan extensa).
El conjunto de Win API se implementa en forma de DLL dinámicas. A continuación, hablaremos sobre la tecnología de uso de DLL en el entorno VB usando el ejemplo de las bibliotecas incluidas en Win API. Sin embargo, cuando se habla de DLL, hay algunos puntos importantes que destacar.
En este caso, por DLL nos referimos a la versión tradicional de las bibliotecas dinámicas binarias, que proporcionan a las aplicaciones acceso directo a los procedimientos necesarios: subrutinas o funciones (de forma muy similar a lo que sucede cuando se llaman procedimientos dentro de un proyecto VB). Estas bibliotecas se pueden crear utilizando diferentes herramientas: VC++, Delphi, Fortran, excepto VB (veamos qué aparece en la versión 7.0); este último sólo puede crear DLL ActiveX, a las que se accede a través de la interfaz de automatización OLE.
Normalmente, los archivos de biblioteca dinámica tienen la extensión .DLL, pero esto no es en absoluto necesario (para Win16 se usaba a menudo la extensión .EXE); Los controladores de dispositivos externos se designan mediante .DRV.
Como ya hemos señalado, es bastante difícil determinar el número exacto de funciones API de Windows y los archivos que las contienen, pero todas están ubicadas en el directorio del sistema. En este sentido, es mejor destacar la composición de las bibliotecas incluidas en el kernel del sistema operativo y las bibliotecas principales con funciones adicionales clave.
Y ahora algunos consejos.
La misma llamada a procedimientos DLL en un programa tiene exactamente el mismo aspecto que a los procedimientos "normales" de Visual Basic, por ejemplo:
Llamar a DllName([lista de argumentos])
Sin embargo, para utilizar funciones DLL externas (incluida la API de Win), deben declararse en el programa mediante la declaración Declare, que tiene este aspecto:
Declarar SubProcedimientoName Lib _ “LibraryName” _ [([ArgumentList])]
Declarar función Nombre de función _ Lib “Nombre de biblioteca” _ [([Lista de argumentos])]
Aquí, los elementos opcionales del operador se muestran entre corchetes, las expresiones variables están en cursiva y las palabras restantes son palabras clave. El sistema de ayuda ofrece una descripción bastante buena de la sintaxis del operador, por lo que por ahora sólo señalaremos algunos puntos.
Las declaraciones de funciones externas deben colocarse en la sección Declaraciones generales del módulo. Si lo coloca en un módulo de formulario, debe especificar la palabra clave Privada (esta declaración solo estará disponible dentro de este módulo); esta es una limitación para todos los procedimientos del módulo de formulario.
El conjunto de API de Win32 se implementa solo en forma de funciones (la API de Win16 tenía muchas subrutinas). En su mayor parte, se trata de funciones de tipo Long, que suelen devolver el código de finalización de la operación.
El operador Declarar apareció en MS Basic en la época de DOS y también se usaba para declarar procedimientos internos de proyectos. En Visual Basic esto no es necesario, ya que la declaración de procedimientos internos es automáticamente su declaración Sub o Función. En comparación con Basic/DOS, la nueva descripción debe indicar el nombre del archivo de la biblioteca donde se encuentra el procedimiento requerido. Las bibliotecas de Wip API se encuentran en el directorio del sistema de Windows, por lo que basta con proporcionar solo el nombre del archivo. Si accede a una DLL que se encuentra en una ubicación aleatoria, debe escribir la ruta completa a este archivo.
La descripción de la declaración Declare suele ocupar bastante espacio y no cabe en una línea de la ventana de código. Por lo tanto, le recomendamos que siga un esquema de salto de línea específico al escribir aplicaciones, por ejemplo:
Declarar función GetTempPath _ Lib “kernel32” Alias “GetTempPathA” _ (ByVal nBufferLength As Long, _ ByVal lpBuffer As String) As Long
En este caso, todos los elementos principales de la descripción están colocados en líneas diferentes y, por lo tanto, son fáciles de leer.
El uso de Win API y varias funciones DLL amplía significativamente la funcionalidad de VB y, a menudo, mejora el rendimiento del programa. Sin embargo, el precio a pagar por esto es el riesgo de reducir la confiabilidad de la aplicación, especialmente durante su depuración.
Una de las ventajas más importantes del entorno VB es la confiabilidad del proceso de desarrollo del programa: al operar bajo el control de un intérprete, el código del programa teóricamente no puede interrumpir el funcionamiento de Windows y del propio VB. Es posible que el programador no tenga mucho cuidado con la exactitud al pasar parámetros a las funciones llamadas. errores similares será fácilmente detectado por el propio intérprete, ya sea durante la traducción del código o durante su ejecución. En el caso más desagradable, el modo de procesamiento simplemente se interrumpirá, con una indicación de dónde y por qué ocurrió el error.
El uso de funciones API de Windows u otras DLL elimina directamente dicho control sobre la transferencia de datos y el proceso de ejecución de código fuera del entorno VB. Por lo tanto, un error al acceder a funciones externas puede provocar la inoperancia tanto de VB como del sistema operativo. Esto es especialmente cierto en la etapa de desarrollo del programa, cuando la presencia de errores es bastante natural. Así, al utilizar las capacidades más amplias de las funciones de la capa base del sistema, el programador asume la responsabilidad del uso correcto de las mismas.
El problema se agrava aún más por el hecho de que diferentes lenguajes de programación utilizan diferentes formas de pasar parámetros entre procedimientos. (Más precisamente, diferentes caminos pasar es el valor predeterminado, ya que muchos lenguajes pueden admitir múltiples métodos). Las API de Win se implementan en C/C++ y utilizan las convenciones de paso de parámetros de ese sistema, que difieren de la versión habitual de VB.
En este sentido, cabe señalar que la aparición de análogos de funciones API integradas en VB se justifica precisamente por la adaptación de estas últimas a la sintaxis de VB y la implementación de un mecanismo de control de intercambio de datos adecuado. Tengamos en cuenta también que en la etapa de depuración experimental de la aplicación al crear un módulo ejecutable, es mejor utilizar la opción de compilación de código P en lugar de código nativo (código de máquina). En el primer caso, el programa se ejecutará bajo el control de un intérprete: más lento en comparación con el código de máquina, pero más confiable desde el punto de vista del posible impacto erróneo en el sistema operativo y proporcionando un modo más conveniente para identificar posibles errores.
El uso de la función API requiere una programación más cuidadosa utilizando algunas técnicas de llamada a procedimientos menos familiares (en comparación con VB). Continuaremos abordando estas cuestiones a continuación. Y ahora presentamos un resumen de los consejos formulados por Dan Appleman sobre este tema (su primera versión apareció en 1993) con algunas de nuestras adiciones y comentarios.
1. Recuerda ByVal. El error más común que se comete al acceder a las funciones API y DLL es el uso incorrecto de la palabra clave ByVal: o se olvidan de ponerla o, por el contrario, la ponen cuando no es necesaria.
Estos ejemplos muestran el impacto del operador ByVal en el paso de parámetros.
| Tipo de parámetro | Con ByVal | Sin ByVal |
|---|---|---|
| Entero | Se inserta un entero de 16 bits en la pila | La dirección de 32 bits de un entero de 16 bits se inserta en la pila |
| Largo | Se inserta un entero de 32 bits en la pila | La dirección de 32 bits de un entero de 32 bits se inserta en la pila |
| Cadena | La cadena se convierte al formato utilizado en C (datos y un byte nulo final). La dirección de 32 bits de la nueva línea se inserta en la pila | El mango VB de la cuerda se empuja hacia la pila. (Estos identificadores nunca son utilizados por la API de Windows y solo se reconocen en archivos DLL implementados específicamente para VB). |
Cabe recordar aquí que el paso de parámetros en cualquier sistema de programación, incluido VB, se realiza de dos formas principales: por referencia (ByRef) o por valor (ByVal). En el primer caso, se pasa la dirección de la variable (esta opción se usa de forma predeterminada en VB), en el segundo, su valor. La diferencia fundamental es que al utilizar una referencia, el valor modificado del parámetro pasado se devuelve al programa que realiza la llamada.
Para comprender esto, realice un experimento utilizando los siguientes programas:
Dim v As Integer v = 2 Llamar a MyProc(v) MsgBox “v = “ & v Sub MyProc (v As Integer) v = v + 1 End Sub
Cuando ejecute este ejemplo, recibirá un mensaje con el valor de la variable igual a 3. El hecho es que en este caso la dirección de la variable v, creada físicamente en el programa que llama, se pasa a la subrutina MyProc. Ahora cambie la descripción del procedimiento a
Sub MyProc (ByVal v Como entero)
Como resultado, al ejecutar la prueba, obtendrá v = 2, porque solo el valor inicial de la variable se pasa al procedimiento; el resultado de las operaciones realizadas en ella no se devuelve al programa que llama. El modo de transferencia por valor también se puede cambiar usando el operador de llamada de la siguiente manera:
Sub MyProc (v As Integer) ... Call MyProc((v)) ' (v) - los paréntesis indican el modo de transferencia por valor.
Sin embargo, al acceder a procedimientos internos de VB, se prohíbe el uso de la palabra clave ByVal en la declaración Call; en su lugar se utilizan paréntesis. Hay una explicación para esto.
En el caso clásico (C, Fortran, Pascal), la diferencia entre los modos ByRef y ByVal depende de qué se coloca exactamente en la pila de intercambio de datos: la dirección de la variable o su valor. Históricamente, Basic utiliza una variante de la emulación del software ByVal: siempre hay una dirección en la pila, pero solo cuando se pasa por valor se crea una variable temporal para esto. Para distinguir entre estas dos opciones (Clásica y Básica), se utilizan diferentes formas de describir el modo ByVal. Tenga en cuenta que emular el modo ByVal en VB proporciona una mayor confiabilidad del programa: al mezclar la forma de referencia, el programador solo corre el riesgo de que el valor corregido de la variable sea devuelto (o no devuelto) al programa que llama. En la versión "clásica", tal confusión puede provocar un error fatal al ejecutar un procedimiento (por ejemplo, cuando se usa un valor de variable igual a, digamos, cero, en lugar de una dirección de memoria).
Las funciones DLL se implementan según principios "clásicos" y, por lo tanto, requieren una descripción obligatoria de cómo se intercambian los datos con cada uno de los argumentos. Las declaraciones de funciones a través de la descripción de Declaración (más precisamente, la lista de argumentos pasados) sirven para este propósito. La forma más común de pasar parámetros a una función API de Windows o DLL es utilizar la palabra clave ByVal. Además, se puede especificar tanto en el operador Declarar como directamente al llamar a la función.
Las consecuencias del paso incorrecto de parámetros son fáciles de predecir. Si recibe una dirección obviamente no válida, recibirá un mensaje GPF (Fallo de protección general). Si la función recibe un valor que coincide con una dirección válida, entonces la función API ingresará a un área extraña (por ejemplo, el kernel de Windows) con todas las consecuencias desastrosas resultantes.
2. Verifique el tipo de parámetros que se pasan. El número y tipo correcto de parámetros pasados son igualmente importantes. Es necesario que los argumentos declarados en Declare coincidan con los parámetros esperados en la función API. El caso más común de error al pasar parámetros implica la diferencia entre NULL y una cadena de longitud cero; recuerde que no son lo mismo.
3. Verifique el tipo de devolución.
VB es bastante tolerante con las discrepancias en los tipos de retorno de funciones, ya que los valores numéricos generalmente se devuelven a través de registros en lugar de la pila. Las siguientes reglas ayudarán a determinar el valor correcto devuelto por una función API:
4. Utilice la construcción “Como Cualquiera” con mucho cuidado. Muchas funciones API de Windows tienen la capacidad de aceptar parámetros varios tipos y utilice la construcción Como cualquier (la interpretación del tipo se realiza dependiendo del valor de otros parámetros pasados).
Una buena solución en este caso puede ser utilizar varios alias (Alias) de una función creando dos o más declaraciones para la misma función, especificando cada declaración parámetros de un tipo específico.
5. No olvides inicializar las cadenas. Hay muchas funciones en Win API que devuelven información cargando datos en búferes de cadena pasados como parámetro. En su programa, aparentemente puede hacer todo correctamente: no se olvide de ByVal, pase los parámetros a la función correctamente. Pero Windows no puede comprobar qué tan grande es el tamaño de la memoria asignada para una fila. El tamaño de la fila debe ser lo suficientemente grande para acomodar todos los datos que se pueden colocar en ella. La responsabilidad de reservar un buffer del tamaño requerido recae en el programador de VB.
Cabe señalar que en Windows de 32 bits, cuando se utilizan cadenas, la conversión se realiza de Unicode (codificación de doble byte) a ANSI (codificación de un solo byte) y viceversa, teniendo en cuenta la configuración del sistema nacional. Por lo tanto, para reservar buffers, a veces es más conveniente usar matrices de bytes en lugar de variables de cadena. (Más sobre esto a continuación).
La mayoría de las veces, las funciones de Win API le permiten definir usted mismo el tamaño máximo de bloque. En particular, a veces esto requiere llamar a otra función API que "indicará" el tamaño del bloque. Por ejemplo, GetWindowTextLength le permite determinar la longitud de la cadena necesaria para contener el título de la ventana devuelto por la función GetWindowText. En este caso, Windows se asegura de que no te excedas.
6. Asegúrese de utilizar la opción explícita.
7. Verifique cuidadosamente los valores de los parámetros y los valores de retorno. VB tiene buenas oportunidades en la verificación de tipos. Esto significa que cuando intenta pasar un parámetro no válido a una función de VB, lo peor que puede pasar es que reciba un mensaje de error de VB. Pero este mecanismo, lamentablemente, no funciona al acceder Funciones de Windows API.
Windows 9x ha mejorado la verificación de parámetros para la mayoría de las funciones API. Por tanto, la presencia de un error en los datos no suele provocar un error fatal, pero determinar qué lo provocó no es tan fácil.
Aquí recomendamos utilizar varias formas de depurar este tipo de error:
Además, es necesario verificar el resultado de ejecutar la función API.
8. Recuerde que los números enteros en VB y en Windows no son lo mismo. En primer lugar, debes tener en cuenta que el término "Entero" en VB significa un número de 16 bits, mientras que en la documentación de Win 32 significa un número de 32 bits. En segundo lugar, los números enteros (Entero y Largo) en VB son cantidades con signo (es decir, un dígito se usa como signo y el resto como mantisa del número), en Windows solo se usan números no negativos. Esta circunstancia debe tenerse en cuenta al formar el parámetro pasado utilizando operaciones aritmeticas(por ejemplo, calcule la dirección sumando alguna base y desplazamiento). Las funciones aritméticas estándar de VB no son adecuadas para esto. Discutiremos qué hacer en este caso por separado.
9. Preste mucha atención a los nombres de las funciones. A diferencia de Win16, todos los nombres de funciones de la API de Win32 son sensibles al uso preciso de minúsculas y letras mayúsculas(Este no fue el caso en Win16). Si en algún lugar usa una letra minúscula en lugar de una mayúscula o viceversa, entonces función requerida no se encontrará. También tenga cuidado de utilizar correctamente el sufijo A o W en funciones que utilizan parámetros de cadena. (Para obtener más información sobre esto, consulte a continuación).
10. Guarde su trabajo con frecuencia. Los errores asociados con el uso incorrecto de DLL y Win API pueden provocar una terminación de emergencia del entorno VB y posiblemente de todo el sistema operativo. Debe asegurarse de que el código que escriba se guarde antes de la ejecución de la prueba. Lo más sencillo es configurar el modo. grabación automática módulos del proyecto antes de ejecutar el proyecto en el entorno VB.
Después de leer los consejos anteriores, puede pensar que utilizar las funciones de Win API es arriesgado. Hasta cierto punto esto es cierto, pero sólo en comparación con la programación segura que ofrece el propio VB. Pero con un uso hábil y conocimiento de los posibles peligros, este riesgo es mínimo. Además, a menudo es simplemente imposible abandonar por completo el uso de Win API; seguirán siendo necesarios para cualquier desarrollo serio.
Además, anteriormente mencionamos los peligros de una amplia clase de archivos DLL. En el caso de Win API todo es mucho más sencillo, ya que la forma de acceso a estas funciones está claramente unificada. Deben tenerse en cuenta los siguientes puntos principales:
Declarar nombre de función y 'tipo de función _ se determina mediante el sufijo
La llamada a la función API se ve así:
Resultado& = NombreApi& ([ Lista de argumentos]
¡ATENCIÓN! Cuando se trabaja en VB, es mejor usar la propiedad LastDLLError del objeto Err para obtener el valor del código de error calificado, ya que VB a veces restablece la función GetLastError entre llamar a la API y continuar ejecutando el programa.
Puede interpretar el código devuelto por GelLastError utilizando constantes escritas en el archivo API32.TXT, con nombres que comienzan con el sufijo ERROR_.
Los errores más típicos tienen los siguientes códigos:
Sin embargo, muchas funciones devuelven el valor de algún parámetro solicitado (por ejemplo, OpenFile devuelve el valor del identificador del archivo). En tales casos, el error está determinado por algún otro valor especial de Return&, normalmente 0 o –1.
Mediante el uso variables de tipo Long realiza al menos el 80% de la transmisión de argumentos. Tenga en cuenta que el argumento Siempre va acompañado de la palabra clave ByVal, y esto, entre otras cosas, significa que se realiza una transferencia de datos unidireccional: desde el programa VB a la función API.
B) ByVal...Como cadena
Este tipo de transferencia de datos también ocurre con bastante frecuencia, y con el argumento también Siempre Se aplica ByVal. Cuando se llama a una función API, la dirección de la cadena se escribe en la pila, por lo que en este caso es posible el intercambio de datos bidireccional. Hay varios peligros a tener en cuenta al trabajar con cuerdas.
La primera es que la reserva de memoria para una cadena se realiza en el programa que llama, por lo que si la función API llenará cadenas, entonces deberá crear una cadena del tamaño requerido antes de llamarla. Por ejemplo, la función GetWindowsDirectory devuelve la ruta a directorio de windows, que por definición no debería tener más de 144 caracteres. En consecuencia, llamar a esta función debería verse así:
WinPath$ = Space$(144) ' reservar una cadena de _ 144 caracteres Result& = GetWindowsDirectory& (WinTath$, 144) _ ' llenado del búfer ' Result& - número real de caracteres en el nombre del directorio _ WinPath$ = Left$(WinPath, Result& )
El segundo problema es que cuando se llama a una función API, la cadena fuente se convierte en alguna representación interna y, al salir de la función, viceversa. Si en la época de Win16 esta operación consistía únicamente en agregar un byte cero al final de la línea, con la llegada de Win32 esto se agregó a la transformación de la codificación Unicode de doble byte a ANSI y viceversa. (Esto se discutió en detalle en el artículo "Características de trabajar con variables de cadena en VB", ComputerPress 10'99 y 01'2000). Por ahora, observemos que al usar la construcción ByVal... As String, puede intercambiar cadenas solo con datos de caracteres.
B) ...Como Cualquiera
Esto significa que alguna dirección del búfer de memoria se enviará a la pila, cuyo contenido será interpretado por la función API, por ejemplo, dependiendo del valor de otros argumentos. Sin embargo, As Any solo se puede usar en la declaración Declare: cuando se llama a una función específica, se debe definir una variable específica como argumento.
D) ... Como tipo definido por el usuario
Este diseño también se suele utilizar cuando es necesario intercambiar datos (generalmente en ambas direcciones) utilizando alguna estructura. De hecho, esta construcción es una especie de implementación concreta de la forma de transmisión As Any, solo que en este caso la función está configurada en una estructura fija.
La forma de la estructura de datos está determinada por la función API específica, y es responsabilidad del programador describirla y reservarla adecuadamente en el programa de llamada. Este diseño Siempre usado sin palabras ByVal, es decir, en este caso, se realiza la transferencia por referencia: la dirección de la variable se escribe en la pila.
Ilustremos lo anterior usando el ejemplo del uso de dos funciones útiles trabajar con archivos: lopen y lread, que se describen a continuación:
Declarar función lopen Lib “kernel32” _ Alias “_lopen” (_ ByVal lpFileName As String, _ ByVal wReadWrite As Long) Como largo Declarar función lread Lib “kernel32” _ Alias “_lread” (_ ByVal hFile As Long, lpBuffer Como Cualquiera, _ ByVal wBytes Mientras) Mientras tanto
En VB, sus análogos, en este caso exactos, son los operadores Abrir y Obtener (para modo binario). Prestemos atención de inmediato al uso de la palabra clave Alias en una declaración de función; este es exactamente el caso en el que no puede prescindir de ella. Los nombres de funciones reales en la biblioteca comienzan con un guión bajo (estilo típico del lenguaje C), que no está permitido en VB.
La operación de apertura del archivo podría verse así:
Const INVALID_HANDLE_VALUE = -1 ' valor de descriptor _ incorrecto lpFileName$ = “D:\calc.bas” ' nombre de archivo wReadWrite& = 2 ' modo lectura-escritura hFile& = lopen(lpFileName$, wReadWrite&) _ ' define el descriptor de archivo If hFile& = INVALID_HANDLE_VALUE Entonces _ ' error al abrir el archivo ' especifica el código de error CodeError& = Err.LastDllError 'CodeError& = GetLastError _ ' esta construcción no funciona End If
Aquí debes prestar atención a dos puntos:
Luego se puede leer el contenido del archivo, pero esto supone que el programador debe tener algún conocimiento de su estructura (como es el caso cuando se trabaja con archivos binarios arbitrarios). En este caso, llamar a la función lread podría verse así:
Dim MyVar As Single wBytes = lread (hFile&, MyVar, Len(MyVar) ' leyendo un número real, 4 bytes ' wBytes es el número de datos realmente leídos, ' -1 es un error... Escriba MyStruct x As Single i As Tipo de extremo entero Dim MyVar As MyStruct wBytes = lread (hFile&, MyVar, Len(MyVar)) ' leer estructura de datos, 6 bytes
Tenga en cuenta nuevamente: el segundo argumento de la función se pasa por referencia, el resto se pasa por valor.
Dim MyVar As String MyVar = Space$(10) 'reservar una variable para 10 caracteres wBytes = lread (hFile&, ByVal MyVar, Len(MyVar)) 'leer una cadena de caracteres, 10 caracteres
Aquí puede ver una diferencia importante con respecto al ejemplo anterior: la variable de cadena va necesariamente acompañada de la palabra clave ByVal.
La lectura del contenido de un archivo en una matriz (para simplificar, usaremos una matriz de bytes unidimensional) se realiza de la siguiente manera:
Dim MyArray(1 To 10) As Byte wBytes = lread (hFile&, MyArray(1), _ Len(MyArray(1))* 10) 'lee 10 elementos de la matriz
Al especificar el primer elemento de la matriz como argumento, estamos pasando la dirección del comienzo del área de memoria reservada para la matriz. Obviamente, puedes llenar cualquier fragmento de una matriz de esta manera:
WBytes = lread (hFile&, MyArray(4), _ Len(MyArray(1))* 5) 'leer los elementos de la matriz 4 a 8
Aquí, basándonos en el ejemplo anterior, revelaremos la esencia del cuarto consejo de Dan Appleman.
Cuando trabaje con la función lread, debe recordar que al acceder a ella usando una variable de cadena, debe usar la palabra clave ByVal (de lo contrario, recibirá mensajes sobre una operación ilegal). Para protegerse, puede hacer más descripción especial la misma función para trabajar solo con variables de cadena:
Declarar función lreadString Lib “kernel32” _ Alias “_lread” (_ ByVal hFile As Long, ByVal lpBuffer As String, _ ByVal wBytes As Long) As Long
Al trabajar con esta descripción, ya no es necesario especificar ByVal al contactar:
WBytes = lreadString(hFile&, MyVarString, _ Len(MyVarString)) '
Parecería que la sintaxis del operador Declare le permite hacer una descripción especial similar para una matriz:
Declarar función lreadString Lib “kernel32” Alias “_lread” (_ ByVal hFile As Long, lpBuffer() As Byte, _ ByVal wBytes As Long) As Long
Sin embargo, el recurso
WBytes = lreadArray(hFile&, MyArray(), 10)
conduce inevitablemente a un error fatal del programa.
Esta es una continuación de la conversación sobre las peculiaridades del procesamiento de variables de cadena en Visual Basic: VB usa codificación Unicode de doble byte, Win API usa ANSI de un solo byte (y con el formato adoptado en C, con un byte cero al final) . En consecuencia, cuando se utilizan variables de cadena como argumento, la conversión de Unicode a ANSI siempre se realiza automáticamente al llamar a una función API (más precisamente, una función DLL) y la conversión inversa al regresar.
La conclusión de esto es simple: las variables de cadena se pueden usar para intercambiar datos de caracteres, pero no se pueden usar para intercambiar información binaria arbitraria (como era el caso con las versiones de 16 bits de VB). En el último caso, es mejor utilizar una matriz de bytes unidimensional.
Como sabes, el tipo String se puede utilizar para describir una estructura personalizada. En este sentido, es necesario recordar lo siguiente:
En el caso de una cadena de longitud variable, se pasa un descriptor de cadena como parte de la estructura con todas las consecuencias consiguientes en forma de error de ejecución del programa.
En este caso, se realiza la conversión de codificación correspondiente.
Y una última nota: bajo ninguna circunstancia debe utilizar una matriz de variables de cadena (tanto de longitud fija como variable) al acceder a una función API. De lo contrario, se garantizará el surgimiento de una “operación ilegal”.
Es probable que se encuentre en una situación en la que necesite escribir sus propias funciones DLL. La necesidad de esto surgirá inevitablemente si utiliza tecnología de programación mixta, utilizando dos o más lenguajes de programación para implementar una aplicación.
En este sentido, observamos que la programación mixta es bastante común para implementar una aplicación bastante compleja. De hecho, cada lenguaje (más precisamente, un sistema de programación basado en un lenguaje) tiene sus propias fortalezas y debilidades, por lo que es bastante lógico aprovechar varias herramientas para resolver diferentes tareas. Por ejemplo, VB - para crear una interfaz de usuario, C - para un acceso eficiente a los recursos del sistema, Fortran - para implementar algoritmos numéricos.
La opinión del autor es la siguiente: cualquier programación seria requiere que el desarrollador domine al menos dos herramientas. Por supuesto, en las condiciones modernas de una clara división del trabajo es muy difícil ser un excelente experto incluso en dos sistemas, por lo que el esquema de "idiomas principales y auxiliares" es más lógico. La idea aquí es que incluso un conocimiento superficial del lenguaje "auxiliar" (escribir procedimientos bastante simples) puede mejorar en gran medida la eficiencia del uso del lenguaje "principal". Tenga en cuenta que el conocimiento de VB, al menos como auxiliar, es hoy en día casi un requisito obligatorio para un programador profesional. Por cierto, en la época de DOS, el conocimiento de los conceptos básicos de Assembler era extremadamente deseable para cualquier programador, incluido el Basic.
De una forma u otra, incluso en el trabajo en grupo, cuando cada programador realiza su tarea específica, todos los participantes del proyecto deben tener una idea de las características de la interfaz de procedimiento en diferentes idiomas. Y sepa que muchos sistemas de programación (incluido VB), además de la interfaz predeterminada, permiten utilizar otros métodos avanzados de acceso a procedimientos que permiten adaptar la interfaz a otro idioma.
Al estudiar la interfaz entre procedimientos, se debe prestar atención a los siguientes posibles errores:
Teniendo todo esto en cuenta, se pueden formular las siguientes recomendaciones:
Pero, ¿qué pasa si la función DLL ya está escrita, por ejemplo, en Fortran, pero su interfaz de entrada no se ajusta muy bien a los estándares VB anteriores? Aquí hay dos consejos. Primero: escriba una función DLL de prueba y úsela para intentar encontrar la llamada deseada del programa VB mediante prueba y error. Segundo: escribir un procedimiento de adaptador en el mismo Fortran que proporcionaría una interfaz simple entre VB y una función DLL con la conversión de estructuras de datos simples en estructuras complejas (por ejemplo, convertir una matriz de bytes multidimensional en una matriz de cadenas).
Entonces: use funciones DLL. Pero mantente alerta...
ComputadoraPrensa 9"2000
Para facilitar el trabajo de sus colegas y proporcionar a todos los programas de Windows una interfaz universal, los programadores de Microsoft crearon una API: "Interfaz de programación de aplicaciones".
Este es un conjunto de funciones y procedimientos que los programas pueden utilizar con mayor frecuencia: mostrar un árbol de directorios, buscar archivos, mostrar una ventana estándar con botones para cerrar, minimizar y maximizar, y muchos otros. Como resultado, un desarrollador que crea un programa para Windows no tiene que pensar y desarrollar subrutinas especiales para mostrar la ventana del programa, la ventana para seleccionar una carpeta y otras operaciones elementales similares; simplemente puede llamar a kernel32.dll o user32.dll. de las bibliotecas que contienen funciones y procedimientos API, la función que él necesita, y ella misma hará todo por él. Existen muchas funciones y procedimientos de este tipo: alrededor de 600.
En el sistema operativo MS-DOS no existía una API: quien se comprometió a escribir un programa para este sistema operativo se vio obligado a pensar e implementar métodos para mostrar imágenes en la pantalla, recibir datos del usuario, de de principio a fin viajando a través del sistema de archivos, dibujando gráficos, si tal posibilidad fuera necesaria 2. Esto hizo que el proceso de desarrollo de programas con una interfaz fácil de usar fuera un proceso muy laborioso; a menudo, el tiempo y el esfuerzo dedicados a crear una interfaz gráfica aceptable para el programa excedían los costos de implementar el propio algoritmo del programa para el cual fue creado. . No en vano, las llamadas aplicaciones de "consola" eran muy comunes, es decir, programas que funcionaban solo desde la línea de comando, sin una interfaz: los datos se ingresaban en la misma línea de comando o se creaban a partir de un archivo especificado en ella. y los resultados se generaron en modo de texto simple.
Con la llegada del sistema operativo Windows, se facilitó enormemente el arduo trabajo de los programadores para desarrollar la apariencia del programa y métodos convenientes para ingresar y enviar información: las funciones API ya se usaban en Windows 3.0. Ahora un programador, si por ejemplo quisiera crear una ventana de entrada de texto o una barra de desplazamiento, sólo tenía que escribir una llamada a la función para mostrar dicha ventana con los parámetros que necesitaba, como cualquier otra función del lenguaje en el que escribió su programa, y no introducir grandes cantidades de código para crear un programa que vuelva a dibujar dicha ventana o barra (siendo consciente de que cuando desarrolle el próximo programa que también utilice dichos objetos, tendrá que desarrollar dicho código nuevamente o intentar utilizar parcialmente el antiguo, adaptándolo a las necesidades este nuevo programa). Por lo tanto, la aparición de las API supuso un avance revolucionario en la tecnología de programación, permitiendo la creación programas necesarios con la cómoda interfaz familiar mucho más rápido, sin preocuparse por detalles rutinarios como la programación de objetos de interfaz estándar para la entrada y salida de información.
En Visual Basic para Aplicaciones (VBA), muchas funciones y procedimientos API se llaman a sí mismos cuando el intérprete ejecuta el programa, por lo que puede usarlos para mostrar ventanas de entrada y salida de texto y dibujar en la pantalla. formas geométricas y otras acciones simples no son absolutamente necesarias: VBA las llama según sea necesario y el programa en él simplemente necesita usar las funciones correspondientes de este lenguaje. Sin embargo, a veces es necesario realizar determinadas acciones para las que no hay análogos en las funciones integradas de VBA o funcionan de forma irracional o demasiado lenta. Por ejemplo, una ventana de selección de carpetas con una imagen de un árbol de directorios (Fig. 5.1) o un programa de búsqueda de archivos (análogo en las funciones de VBA, el objeto "Application.FileSearch", funciona demasiado lento con una gran cantidad de archivos). Para tales casos, VBA ofrece la posibilidad de llamar a funciones API.
Desafortunadamente, el uso de funciones API en VBA no está documentado en la ayuda, por lo que para aprender a usarlas debe buscar libros o fuentes en línea sobre programación de Office, o analizar el código de programas que contienen llamadas a funciones API.
En la gran mayoría de los casos, al programar para Office, puede prescindir del uso de la API, pero a veces simplemente llamar a una función de la API puede lograr el resultado deseado. Digamos que necesita asegurarse de que se llamen diferentes macros cuando simplemente hace clic en un botón en una barra de herramientas de Word con el mouse y cuando presiona simultáneamente este botón y la tecla Mayús o Control. Aquí hay un fragmento de código que hace esto:
Declarar la función GetAsyncKeyState Lib "user32.dll" (ByVal kState siempre) como entero
GetAsyncKeyState(vbKeyShift o vbKeyControl)
Si GetAsyncKeyState (vbKeyShift) entonces
Llamar macro1: Salir de Sub
De lo contrario, GetAsyncKeyState (vbKeyControl) entonces
Llamar macro2: Salir de Sub
La primera línea es como "reservar" una función API para usar en un programa VBA. Se puede ver que la función GetAsyncKeyState se llama desde la biblioteca (un archivo que contiene programas destinados únicamente para ser utilizados por otros programas) user32.dll, y el número de clave se pasa a esta función y devuelve un número entero (es decir, 0, si no se pulsa la tecla con el número correspondiente, y -32767 o 1 si se pulsa). Cualquier función o procedimiento llamado desde bibliotecas que no sean VBA debe reservarse mediante el comando Declarar.
La frase vbKeyShift en el comando es un sustituto del código de la tecla Shift (su valor es 16) y vbKeyControl, como es fácil de entender, es un sustituto del código de la tecla Control. La estructura de las declaraciones "Si... Entonces" parece ser clara 3, pero si no, busque en la ayuda de VBA. El comando Llamar antes del nombre de la macro, como recordará, significa ejecutarla.
Hay sitios rusos en Internet dedicados a API 4. Visítelos para obtener más información sobre este conjunto de funciones.
Este Corto plazo escuchado por todos los que han tenido alguna experiencia con el desarrollo. Pero no todo el mundo entiende qué significa exactamente y por qué es necesario. Desarrollador Peter Gazarov Habló sobre la API en palabras simples en su blog.
La abreviatura API significa "Interfaz de programación de aplicaciones" (interfaz de programación de aplicaciones, interfaz de programación de aplicaciones). La mayoría de las grandes empresas desarrollan en algún momento API para clientes o para uso interno. Para comprender cómo y cómo se utilizan las API en el desarrollo y los negocios, primero debe comprender cómo funciona la World Wide Web.
Se puede considerar la WWW como una enorme red de servidores interconectados en los que se almacena cada página. Una computadora portátil normal se puede convertir en un servidor capaz de dar servicio a un sitio web completo en la red, y los desarrolladores utilizan servidores locales para crear sitios web antes de abrirlos a una amplia gama de usuarios.
Cuando se ingresa en la barra de direcciones del navegador www.facebook.com Se envía la solicitud correspondiente al servidor remoto de Facebook. Una vez que el navegador recibe la respuesta, interpreta el código y muestra la página.
Cada vez que un usuario visita una página en la web, interactúa con la API. servidor remoto. La API es el componente del servidor que recibe solicitudes y envía respuestas.
Muchas empresas ofrecen API como producto listo para usar. Por ejemplo, Weather Underground vende acceso a su API de datos meteorológicos.
Escenario de uso: En el sitio web de una pequeña empresa hay un formulario para concertar citas para clientes. La empresa quiere integrar Google Calendar para brindar a los clientes la posibilidad de crear automáticamente un evento e ingresar detalles sobre una próxima reunión.
Aplicación API: El objetivo es que el servidor del sitio se comunique directamente con el servidor de Google con una solicitud para crear un evento con los detalles especificados, recibir la respuesta de Google, procesarla y enviar la información adecuada al navegador, por ejemplo, un mensaje de confirmación al usuario. .
Alternativamente, el navegador puede realizar una solicitud a la API del servidor de Google sin pasar por el servidor de la empresa.
Técnicamente, la diferencia está en el formato de la solicitud y la respuesta. Para generar una página web completa, el navegador espera una respuesta en el idioma marcado HTML, mientras que la API de Google Calendar simplemente devolverá datos en un formato como JSON.
Si el servidor del sitio web de una empresa realiza una solicitud a la API, entonces es el cliente (al igual que el navegador es el cliente cuando el usuario abre el sitio web).
Gracias a la API, el usuario tiene la oportunidad de realizar una acción sin salir del sitio web de la empresa.
La mayoría de los sitios web modernos utilizan al menos algunas API de terceros. Muchas tareas ya cuentan con soluciones listas para usar ofrecidas por desarrolladores externos, ya sea una biblioteca o un servicio. A menudo resulta más fácil y fiable recurrir a una solución ya preparada.
Muchos desarrolladores distribuyen la aplicación a varios servidores, que interactúan entre sí mediante la API. Los servidores que realizan una función de soporte al servidor de aplicaciones principal se denominan microservicios.
Entonces, cuando una empresa ofrece una API a sus usuarios, simplemente significa que ha creado una serie de URL especiales que solo devuelven datos como respuesta.
A menudo, estas solicitudes se pueden enviar a través de un navegador. Dado que la transferencia de datos HTTP se produce en forma de texto, el navegador siempre podrá mostrar la respuesta. Por ejemplo, a través de un navegador puedes acceder directamente a la API de GitHub (https://api.github.com/users/petrgazarov), sin token de acceso, y recibir esta respuesta en formato JSON:
El navegador muestra perfectamente la respuesta JSON, que se puede insertar en el código. Es bastante fácil extraer datos de dicho texto para utilizarlos a su discreción.
La palabra "aplicación" puede tener diferentes significados. En el contexto de la API, esto significa:
Cualquier software que pueda distinguirse claramente del entorno puede sustituir la letra “A” en una abreviatura en inglés, y también puede tener algún tipo de API. Por ejemplo, cuando un desarrollador implementa una biblioteca de terceros en el código, se convierte en parte de toda la aplicación. Como software independiente, la biblioteca tendrá algún tipo de API que le permitirá interactuar con el resto del código de la aplicación.
En el diseño orientado a objetos, el código se representa como una colección de objetos. En una aplicación, puede haber cientos de objetos de este tipo interactuando entre sí. Cada uno de ellos tiene su propia API: un conjunto público propiedades y métodos para interactuar con otros objetos en la aplicación. Los objetos también pueden tener privado, lógica interna que está oculta al entorno y no es una API.
