In una libreria con molti codici, alcuni dei quali sono l'API che l'utente userebbe per interagire con la libreria, come dovrei chiamare il resto del codice che non fa parte dell'API direttamente?
In altre parole, qual è l'opposto dell'API chiamato? Codice interno? Codice privato?
Sembra davvero semplice ma non riesce a trovare la terminologia corretta!
Un'API ( Application Programming Interface ) è (secondo wikipedia )
[...] a set of routine definitions, protocols, and tools for building software and applications.
An API expresses a software component in terms of its operations, inputs, outputs, and underlying types, defining functionalities that are independent of their respective implementations, which allows definitions and implementations to vary without compromising the interface.
In particolare, un'API è una convenzione o un insieme di definizioni, quindi è non il codice sorgente . In altre parole, un'API è principalmente un contratto sociale tra sviluppatori (implementatori di alcune librerie o utenti di quella libreria) documentati in alcuni rapporti.
Quindi, non ha senso parlare del codice sorgente che appartiene a (o di essere in) un'API.
Ovviamente, un'API è implementata da qualche codice sorgente. In pratica, mi aspetto che tutto il codice sorgente di una libreria che implementa un'API sia rilevante (eccetto forse alcuni artefatti interni, come generatori di codice specializzati usati per costruire la libreria, o qualche codice della suite di test).
Alcune API hanno diverse ("equivalenti") librerie che le implementano. Un tipico esempio è la libreria standard POSIX C (su un sistema Linux): la maggior parte dei sistemi Linux utilizza GNU libc , ma alcuni stanno usando il musl-libc , e sia GNU libc che musl-libc stanno implementando la stessa stessa API (forse con estensioni specifiche per ogni libreria), e potresti avere un sistema Linux con entrambi . Allo stesso modo, la (grande) libreria standard C ++ 11 ha diverse implementazioni (la maggior parte dei compilatori C ++ 11 fornisce la propria libreria standard C ++ 11).
(quindi la mia opinione è che tu sia confuso)
PS. In pratica, le cose non sono sempre così belle. Consulta la Legge di Leaky Abstraction di Joel e leggi The Mythical Man-Month
Il termine più comune, in base alla mia esperienza, è internals . Per esempio. Sentirai spesso i ragazzi di C # parlare degli "interni .NET". Analogamente, un programmatore Win32 potrebbe fare riferimento a "Interni di Windows". Anche se non l'ho mai sentito, nel mondo di Linux troverei molto divertente sentire qualcuno dire "interni del kernel".
Esempi di titoli di libri da Amazon:
Si potrebbe pensare a un modello in cui un servizio espone un'API tramite un insieme di endpoint di servizio. Un'implementazione comune, ad esempio, è per un certo numero di classi che implementano gli endpoint REST come API, con quelle classi che hanno poca logica di business, invece fanno validazioni e traduzioni, quindi passano la chiamata a un componente interno, non esposta, per eseguire l'effettiva operazione.
In questo caso, alcuni nomi che potrebbero avere senso sono facade per quel livello API. Potresti avere diverse facciate (REST, SOAP, COM) che avvolgono tutte le implementazioni principali, che potrebbero essere chiamate classi implementazione del servizio o logica aziendale .
Leggi altre domande sui tag api source-code terminology