Как работают web api и нужны ли им серверы
Какая архитектура обмена данными между приложением WebAPI, например написанных на c#, java или других компилируемых языках и сервером?
Когда я пишу какой-нибудь контроллер, то у каждого прописывается часть пути в URL на программном уровне в c#. Зачем тогда этому приложению нужен сервер? Сколько связанных задач в диспетчере будет отображаться: сервер и webapi? Достаточно ли одного webapi? Ведь, как я понимаю, webapi является отдельным процессом, который прослушивает установленный внутри кода порт и обрабатывает его. Зачем тогда нужен ещё и сервер? Это два связанных процесса или модульных (независимых)? Или процесс api запускается при каждом запросе к серверу? Тогда нагрузка на процессор будет высокой.
UPD: под сервером я подразумеваю процесс типа IIS или APACHE. Нужна ли они, если webapi сам является процессом, прослушивающий определенный для него порт?
UPD2: похоже, я нашла ответ: https://habr.com/ru/post/426957/. Коротко: сервер всего-то перенаправляет запрос в связанный процесс webapi. Но остаётся вопрос, как происходит передача данных в обратном направлении?
UPD3: в вопросе я рассматриваю одну часть - пк, который выступает как сервер. Предполагается, что на нём работает два процесса: серверное приложение типа IIS, и второе - webapi (на c#). Потому что все webapi asp.net запускаются из-под IIS или другого сервера. И вопрос был в том, зачем нужен IIS, если все настройки подключения к сокету и маршрутизация уже программируются в webapi. https://habr.com/ru/company/microsoft/blog/145178/
Мда... Наверное ответ лежал на поверхности. Похоже iis реально просто запускает процесс и перенаправляет ему запросы, и обе части являются серверным приложением. И по сути, приложение asp.net может так же работать без iis, т.к. что iis, что webapi работают на определённом порту. Вопрос только в том, кому отправлять клиентские запросы. https://metanit.com/sharp/aspnet5/2.7.php
И цитата из статьи https://habr.com/ru/company/microsoft/blog/145178/ немного приоткрыла ответ:
Для предоставления доступа к API сервиса не всегда является целесообразным разворачивать его на базе сервера IIS. Если сервис не является частью какого-либо веб-приложения, имеет смысл запускать его на базе собственной инфраструктуры.
Как уложу информацию, постараюсь написать ответ.
Ответы (1 шт):
Судя по тому, как много у Вас отдельных маленьких вопросов в одном общем вопросе - у Вас какая то каша в понимании архитектуры веб приложений...
Давайте по порядку.
Вот есть код. Который должен выполниться в ответ на некоторый реквест. Так как Вы говорите про "пути на программном уровне" - значит, про маршрутизацию запросов Вы знаете.
И этот код написан, к примеру, на C#. Или на java.
Нужен ли такому коду сервер? Конечно, нужен! Иначе этот код просто некому будет выполнить.
Дальше - начинаются игры с тем, как оптимально - в смысле производительности (throughput) и времени ответа - загрузить сервер процессами, которые будут отвечать пользователю. Но это - уже совсем другая история, сейчас Вам достаточно знать, что web-сервер - это отдельный процесс.
Дополнение, дополненное после комментария "Но если приложение, которое обрабатывает запрос способен работать без сервера, зачем он тогда им?":
Также, Вы можете прочитать вот таккие вот вопрос-ответ: Что такое сервер приложения?
Теперь попробую кратко ответить на комментарий.
Смотрите. Есть некая путаница в терминах. В основном - потому что людям лень каждый раз говорить "Рестфул приложение, хранящее своё состояние и взамиодействующее по расширенному протоколу HTTP с сервером Apache", и они говоря просто "клиент" или "сервер".
Сервер - любая "штука", которая позвоялет еще кому то - людям или программам - использовать свои ресурсы.
Когда Вы делаете более-менее сложную вещь, то часть "работы" выполняет сервер. Это происходит на логическом уровне. Возьмём в качетве примера игру, где ингроки ходят по полю и наперегонки ищут клад (или мину и возможность на неё подорваться...). В этом слкчае логично, что клиент на самом деле не знает, где находится клад. Иначе он мог бы "хакнуть" программу и воспользоваться этим знанием, получив нечестное преимущество. Поэтому эта информация на логическом уровне должна быть известна только серверу.
Дальше ничанаются частности: а по какому протоколу обращаться к серверу? По кастомному (то есть, только что сами придумали?). Или по какому то известному?
Исторически сложилось так, что HTTP прижился в качестве универсального протокола. И если у Вас есть програма, которая делает что то простое и понятное, но её надо разделить на клиент и сервер - то Вы уже на автомате делите её на две части, и делаете так, что сервер "обмазывается" прослойкой для обработки HTTP - запросов (это и есть стандартна работа WEB-сервера).
Если мои объяснения не помогли - уточните вопрос, например, исправив его. Или напишите в комментариях, еще подумаем.