Я имел ввиду, мне проще своими глазами увидеть исходники GUI и разобраться как оно там работает, чем читать про API; хотя у меня вообщем-то неправильный подход к этому, просто мне так удобнее, так я вижу более целостную картинку.

у меня более широкое видение значит. Например COM интерфейс тоже предоставляет функциональность, но с конкретным ЯП никак не связан, дело выбора программиста, использующего эту функциональность.


интерфейс я имел ввиду не UI, а интерфейс взаимодействия с той же библиотекой или API. Ведь если Вы используете ту или иную библиотеку Вы сталкиваетесь с ее интерфейсом. Набор классов или функций это и есть ее интерфейс, через него ваша программа взаимодействует с самой библиотекой.



ОС - это операционная система. Это контраргумент насчет посредника, имелось ввиду что посредник всегда есть


и не нужно, так как не нужно смешивать эти понятия вообще, они разные по сути.

посмотрите с другой стороны, если так будет проще, что Вам мешает написать такую либу
function ClientAdd(Name)
{
// тут вызов по удаленному url, обработка задокументировнного ответа, возврат результата
}

вот Вам и либа, которую уже можно назвать API
Есть сигнатура: ClientAdd(Name)
Есть семантика: данная функция добавляет клиента, скажем в биллинговую систему.



Сделал и сейчас делаю


Согласен. Согласны, что вызов функции тоже имеет свой внутренний протокол? То есть, как передаются аргументы, как они приходят, в каком порядке ложатся в стек. Только зачем нам знать об этом, пусть SOAP себе протокол и мне вообще все равно, как пользователю использующему какую-то функциональность по какому протоколу это работает, мне интересно только то, что при передачи функции таких-то параметров, я могу получить такой-то результ, все. Больше меня не интересует ровным счетом ничего, если такая функция работает и использует какую-то внешнюю функциональность, значит я использую внешний API или сервис. Для меня сервис это подмножество понятия API, может, конечно, я и заблуждаюсь, но живу с этим

"
Интересная постановка вопроса Найдите мне в стандарте языка C++ упоминание про API Но это же еще не значит, что на C++ никто не писал API. Уловили?


Тут вставка HTTP и SOAP скажем так сужает ту абстракцию, которую хочет передать автор. Он имел ввиду протокола вообще. То есть HTTP это протокол передачи данных. Тут мы все согласимся. Есть протокол передачи данных при вызове одной функции из другой. Тоже согласимся, правильно? То есть протокол, это как порядок, стандарт и т.д. передачи данных. Получается, что если я вызываю функцию, то использую протокол передачи данных в любом случае. Почему же тогда для вызова функции из API я не могу использовать протокол HTTP. Имелось ввиду то, что и протокол и API это некие стандарты, этим они и близки по смыслу, просто API это стандарт на описание сигнатур и семантики функций (там же взял). А протокол - это стандарт передачи данных. То есть, если я опишу эти два понятия для сервиса SOAP, сигнатуру и семантику функций, этот сервис по определению станет API. Теперь Вы согласны?

Случайно вспомнилось про эту тему, интересно она развивалась.
Сейчас можем короче сформулировать свою мысль по поводу "почему у ДА не API, а просто описанный интерфейс возможного взаимодействия".
По одной простой причине - не все его возвращаемые значения действий могут однозначно интерпретироваться программой, человеком - да, программой - нет.

Гы Коротко и ясно.

а что, da уже начал результаты работы выдавать графикой на зашумлённой картинке, чтобы усложнить жизнь программистам?

По Вашему API это когда нет графики на зашумленной картинке ?

API - это когда перестаните притягивать к этому определению всякую ересь.
"не все", "могут однозначно интерпретироваться" - и это слова настоящего программиста?
не можете Вы - так и признайтесь в этом :-) а не сваливайте всё на три буквы...