Nulltiton

Думаю тут стоит уточнить контекст, что и где разрабатывать. К примеру я один раз при написании прошивки для ардуинки - забыл удалить библиотеку и долго не мог понять, почему не хватает памяти. Как только нашёл лишнюю подключенную библиотеку и удалил её - всё завелось без проблем))
Так что на производительность возможно и не влияет, но место занимает :)

Вопрос о наличии в памяти неиспользуемых библиотек изучен слабо.
Теоретически можно предположить, что при загрузке всё лишнее отключаются. Тогда - не влияет никак.
А если не отключается - то влияет, но размер доступной памяти уменьшается на размер библиотек.
Хуже с библиотеками, в которых тебе нужны несколько методов, а оставшиеся десятки мегабайт - только балласт. Пример - биб-ка smile (Java), содержащая десятки мегабайт исполняемого кода по всем направлениям математической статистики, а нужно только корреляцию Пирсона посчитать.
Тут, скорее всего, вся библиотека грузится, но используется, дай разум, 1% от её общего размера.

В своё время в Delphi нравилось то, что при сборке EXE из объектных (откомпилированных) модулей подключались лишь те, на которые были ссылки.
Если современные среды разработки способны на такое, то было бы полезно все библиотеки подключать в виде исходных кодов и компилировать в свою собственный исполняемый модуль.
Это дало бы максимальные эффект по оптимизации памяти.

Вы о Using что ли?
На производительность у конечного пользователя - не влияет, оптимизатор их вырежет.
НА производительность у вас - ну немного влияет, но вы этого не заметите

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

API - это буквально интерфейс, т.е. способ (абсолютно любой, хоть через .txt файлы) взаимодействия с программой.
Если вы не соблюдаете интерфейс, то вы не можете взаимодействовать с программой программным способом. Если вы пишете интерфейс, то другие обязаны следовать вашей инструкции.

Правильно ли я понимаю, что

API может быть любым. Но чаще используют некоторые удобные общепринятые шаблоны, например: web json rest api, интерфейсы в c# или dll библиотеки.

API - это не само приложение, а описание того, как одно приложение может взаимодействовать с другим.

В случае winapi - это описание того, как ты можешь взаимодействовать с виндой (как раз через вызовы определённых функций)

В случае веба - описание того, какие http запросы ты должен слать для совершения тех или иных действий.

Консольное приложение в принципе может быть некоторый способом для взаимодействие с чем-то - git тому пример, но у консольного приложения тоже есть свой контракт

1. Именование методов и классов: CheckId, ResponseProcessing, RequestClass, APIClass.

2. Лютая процедурщина с повсеместным использованием static.

3. Большинством соглашений принято писать "public static", а не "static public"

4. .Result внутри асинхронного метода

5. .Result внутри обработчика события чтобы дождаться чего-то, что в этом же обработчике и запущено через Task Run

6. лично я всё ещё против использования httpListener

7. Странный код внутри Check id

Для этого вставте вашу функцию внутрь while (true) { ... }

Альтернатив - миллионы. Есть библиотеки которые предоставляют доступ к файлам наподобие баз данных. Это LevelDb например.

Но обсуждать этот вопрос глубоко - нет смысла т.к. неясны требования к твоей системе хранения.

Если тебе достаточно файлов (csv, json, xml) то ради бога! Храни в файлах. Это будет очень даже
экономно с точки зрения TCO и никакой админ не нужен. А вот когда ты будешь гонять запросы
по файлам и тебе понадобится индексирование, транзакции и изоляция - вот с этого момента
можно обуждать всякие dbms или системы на файлах.

Есть же поиск: https://letmegooglethat.com/?q=%D0%B4%D0%B2%D0%BE%...