Application programming interface: differenze tra le versioni

Versione delle 22:09, 4 feb 2009

Versione delle 18:50, 2 mar 2009

Riga 18:

Ovviamente, l'approccio del primo livello richiede molti passaggi ed ognuno di questi è molto più complesso di quelli dei livelli successivi. Altro svantaggio del primo approccio è che è poco pratico utilizzarlo nel caso in cui sia necessario visualizzare una certa quantità di informazioni sullo schermo, col secondo approccio l'operazione è molto più semplice e nel terzo è sufficiente scrivere "Hello World". In genere utilizzare API di livello più alto di solito comporta una certa perdita di flessibilità; per esempio, potrebbe essere molto difficile a livello di web browser ruotare attorno ad un punto un testo con i bordi lampeggianti, mentre questo compito potrebbe essere svolto in modo semplice ad un livello più basso. Questa differenza è un tipico esempio di compromesso che si può incontrare utilizzando un'API.

Le API sono essenziali per i computer come gli standard elettrici lo sono per una [[casa]]. Chiunque può inserire la spina del tostapane nella presa a muro della sua casa o dal vicino perché entrambe le case sono conformi ad uno standard. Se non ci fosse una interfaccia standard, occorrerebbe avere una centrale elettrica per fare un ''toast''. Niente vieta che esistano più tipi di interfacce diverse, per esempio un tostapane europeo non può funzionare negli Stati Uniti senza un [[trasformatore]] similmente ad un programma scritto per [[Microsoft Windows]] che non può essere eseguito direttamente su un [[Unix| sistema UNIX]] senza un ''[[API adapter]]'' come [[WINE]].

Esistono vari [[design model]] per le API. Le interfacce intese per la massima velocità di esecuzione spesso consistono in una serie di [[Subroutine|funzioni]], [[procedura|procedure]], [[variabile|variabili]] e [[struttura dati|strutture dati]]. Esistono anche altri modelli come gli [[interprete (software)|interpreti]] usati per valutare le espressioni come con [[ECMAScript]]/[[Javascript]]. Una buona API fornisce una "scatola nera" o un livello di astrazione che evita al programmatore di sapere come funzionano le API ad un livello più basso. Questo permette di riprogettare o migliorare le funzioni all'interno dell'API senza cambiare il codice che si affida ad essa.

Riga 46:

* ''Common Object Request Broker Architecture'' ([[CORBA]])

* ''Java APIs for Integrated Networks'' ([[JAIN]])

* ''Simple Network Management Protocol'' ([[Simple Network Management Protocol|SNMP]])

* ''Universal Plug and Play'' ([[UPnP]])