hVosttя неправильно написал. прошу прощения. не у WebAPI проблем выше крыше, а при использовании WebAPI начинаются проблемы (применительно к тем, кто начинает его использовать вместе с MVC). как только примеры начинают усложнятся, все становится не так очевидно, как на учебных примерах. ты сам его использовал в боевом режиме? или только голая теория?
А зачем в ASP.NET MVC использовать WebAPI, этот фреймворк изначально заточен под RESTful архитектуру. Я привел пример клиента на WebAPI, который запрашивает веб ресурс. У автора два приложения, одно из которых должно обратиться к первому - чем не устроило взаимодействие через WebAPI?

hVosttЕсли так рассуждать, то абсолютно что угодно, запущенное в венде — асинхронно, так как все приложения в венде выполняются параллельно, значит все что там запускается тоже асинхноррно. природа, понимаешь ли, такая у него.
Опять мимо кассы. Асинхронность в самой песочнице, а не за ее кулисами. Возьми дефолтное winforms приложение - откуда там асинхронность? Возьми ASP.NET - он асинхронен. Включи голову.

hVosttНе гони. Платформа ASP.NET не асинхронна, каждый запрос захватывает поток из пула и пользуется им единолично, пока не вернет в пул, количество потоков ограничено, между собой они никак не связаны. Поэтому разница между асинхронной и синхронной обработкой запросов колоссально огромная, зачем придумывать какую-то мифическую «асинхронность» платформы.
Садись, двойка. В конкретный промежуток времени может быть запрошено 100 ресурсов. ASP.NET обратится в пул и возьмёт максимально возможное кол-во потоков (пусть будет 50). Эти 50 тредов будут работать параллельно, в чём и заключается асинхронность природы ASP.NET. Остальные клиенты будут ждать своей очереди, пока не будет доступен первый освободившийся поток.

hVosttсложность в низкоуровневости, несколько другой парадигме программирования (одни и теже задачи, решаются по-другому в отличие от MVC, например аплоад файла), асинхронности и в том, что веб-апи не предлагает нативного способа проталкивать мету на клиента, отсюда вся «честность» модели сводится к значениям полей, что не так уж и круто, как кажется на первый взгляд.
Какой-то феерический бред...

hVosttдискурс имеет смысл, если мы говорим про имеющийся опыт в ASP.NET MVC (и наличию чего-то готового на нём) и прикручивании внезапно едеального WebApi, который ты внезапно советуешь.
Не нужно мешать всё в одну кучу. Я говорю о применении WebAPI вне MVC. Либо в MVC, но в рамках обращения к стороннему RESTful ресурсу.

hVosttЧто значит, зачем?... он не заточен под архитектуру RESTful, он её реализует , и пофигу где его использовать совершенно, но надо учитывать, что он другой. и зачем приводить пример запроса WebAPI по адресу, где у автора располагается обычный Action из ASP.NET MVC, в чем хитрый прикол этого действия? ))
Другой, никто и не спорит - фича особенно актуальна для WebForms. Я ж написал, пример запроса WebAPI для вызова другого приложения. Речь не об использовании фишки для текущего приложения. Так или иначе, ты не ответил на мои вопросы по поводу унылости WebAPI. Агрумент "он другой" не канает, прости.

hVosttДа таже фигня! Один пользователь в ASP.NET — один поток, очень грубо говоря конечно. Запусти несколько копий winforms приложения, и, вуаля!, у нас асинхронный пул вин-приложений! )) Бред несешь.
Ни в коей мере, пользователь никак не коррелирует с потоком. С потоком коррелирует реквест.
Пример с несколькими копиями некорректен, т.к. нет единой платформы, которая выполняет синхронизацию и всячески управляет потоками. Ты эти глупости поди в садике расскажи, и то детишки посмеются.

hVosttНу и толку? В контексте веб-приложения мы обрабатываем запрос. Что там «снаружи» творится, по барабану. Также как и winforms-у по барабану, что он работает параллельно с кучей служб и приложений. А в контексте потока (обработки запроса) никакой асинхронности нет и в помине. Но! Что касается WebAPI и асинхронных контроллеров — соврешенно другое дело. Так что не включай софистика. Природа ASP.NET очень даже синхронна так то, это IIS ему выдает потоки из пула.
О снаружи речи не идет, речь о том, что ASP.NET - это отдельная асинхронная песоцница. Учи матчасть, а не генери глупости. Про выдачу потоков IIS'ом пруф будет?

hVosttНу хз. Я так понял с практикой у тя туга, судя по тому что ты говоришь, наличенствуют по предмету только теоретические познания.
Я уже понял, что с тобой даже о теории бессмысленно говорить. "Он другой" - отличный аргумент.

hVosttНу а речь-то в топике идёт о MVC. Ты бы еще WebForms посоветовал. Да чего уж там, кидай автору код, как можно решить его задачу на PHP.
Ты вообще в вакууме?

hVosttКлассически ASP.NET: один запрос — один поток.
Ты же говорил: один пользователь - один поток? Видишь, как полезно читать доки - молодец, уже лучше.

hVosttВ рамках запроса поток один. То, что страница может генерировать десятки запросов и сервер должен их обработать, это уже архитектура Web в целом, а не исключительно ASP.NET и не надо причесывать все под одну гребенку.
Какая каша, особенно в голове. Что значит "страница может генерировать десятки запросов", ты, вообще, о чем?

hVosttОбрабатывая запрос, если не будешь использовать async/await и еже с ним, все операции будут выполняться строго последовательно.
Забудь про async/await и иже с ними, мы не рассматриваем асинхронные вызовы прикладных методов. Это никаким образом не относится к асинхронности самой платформы.

hVosttНе путай теплое с мягким! Если мы уже в этом простом вопросе путаемся, что асинхронно, а что нет, толку говорить о WebAPI (и о том, почему вот именно он истино натурально асинхронен), — нет. Сначала идем учим матчасть, разбираемся с понятием "асинхронно", потом продолжаем разговор ))
Путаешься, по всей видимости, пока только ты. Я в самом начале конкретно написал: ASP.NET априори асинхронен. В ответ ты начал писать всякие глупости про async/await и прочую белиберду. Что еще раз доказывает то, что ты не в теме.

P.S. Аргументы по поводу унылости WebAPI когда будут?

hVosttМСУ, винда и винформс тоже априори асинхронны . все твои рассуждения про ASP.NET не подходят разве что какому-нибудь DOS-у.
Винформс априори не асинхронен, в отличие от ASP.NET. В ASP.NET же все реквесты выполняются в отдельном треде. Не нужно молоть языком как помелом, говоря глупости, от которых заворачиваются уши.

hVosttв ASP.NET атомарно — это обработка запроса. где все выполняется синхронно.
ASP.NET не ограничивается одним запросом, на каждый последующий запрос будет выделяться соответствующий тред. А то, что выполняется в отдельном треде - никого не интересует.

hVosttможно вернуть поток в пул раньше, чем выполнится обработка запроса. можно, но по умолчанию так не делается. в WebAPI делается. что блин неясного? зачем эти вокруг-да-около вокруг терминов с приплетаением своего бреда?, да еще ASP.NET песочницей обозвал....
Каким образом ты освободишься от потока, если он не закончил работу? Ну-ка с этого места поподробнее, с чего это вдруг в WebAPI поток возвращается в пул раньше, чем отработал запрос, что это за феерическая бредятина такая. Где пруф?

hVosttя нигде не говорил про «унылость», мало того, что ты бредишь, еще и выдумываешь на ходу, свои слова за чужие выдаешь ))
Я тебе уже раза 3 повторил твои слова в адрес WebAPI. Ты долго будешь дурака включать и когда мы дождемся аргументов?

hVosttну ладно-ладно.... я об этом уже говорил, но ты соизволил проигнорировать, ок, еще раз: у модели есть мета-информация (required, stringlength, range, etc.), которая в WebAPI не имеет поддержки. если в MVC это решается путем генерации меты в разметку (data-*), то в WebAPI эта информация тупо теряется. что скажешь? и это далеко не все конечно... а на детских примерах все выглядит идеально, о чем я и сказал.
Причем тут RESTful архитектура WebAPI и атрибутивная логика модели? Ты, вообще, понимаешь, какой бред сейчас пишешь?

hVosttМСУ, если копнуть глубже, винформс тоже асинхронен априори. многие вещи в ui из стандартного: вплывающие подсказки, меню, и т.п. — все эт работает и не тормозит работу приложения во время прорисовки. вообще там много чего есть, бэкграундворкеры всякие, и другого, так что сложно назвать винформс (по твоей же логике) синхронным. так что не моли чушь.
Опять ты блистаешь безграмотностью. Копай или не копай, WinForms выполняется в single thread apartment, никакой асинхронности там нет в помине. Только если ее самому не программировать. Про sta рассказывать, школота? Опять двойка, присаживайся.

hVosttа на счет освобождения потока в ASP.NET в асинхронном режиме, гоу читать маны. блин навалом по теме, начиная от сравнительных тестов, убедительно доказывающих, что асинхронные контроллеры в MVC работают быстрее (как? почему?), заканчивая нативной поддержкой асинхронных действий в MVC 4 (можно вернуть Task<ActionResult> и отдать поток в пул максимально быстро). в общем, rtfm, rtfm и еще раз rtfm, как завещал великий rtfm ))
Я тебе десятый раз повторяю, меня не интересуют прикладные методы и их синхронный или асинхронный вызов. Ты не понимаешь этого? Ты ляпнул, что "можно вернуть поток в пул раньше, чем выполнится обработка запроса". Я таки не вижу еще пруфа. Он будет? Чесать языком каждый может.

hVosttразница между синхронной и асинхронной обработкой запросов есть, но ты её не чувствуешь, не видишь, не понимаешь. для тебя ASP.NET итак уже асинхронен априори , и по барабану. без причин и объяснений. просто так блин :)
Я тебе говорю не о разнице между синхронной и асинхронной обработкой запросов, я тебе говорю о том, что ASP.NET запросы отрабатывает асинхронно. И именно он запрашивает пул потоков. Помнится, имелась хорошая статейка по этому поводу, почему в .NET 4.0 платформа ASP.NET может оперировать большим числом потоковт и резервируемой памяти, в отличие от .NET 2.0.

hVosttну а на счет WebAPI, я те дал проблемный кейс. на что ты ответил «не в кассу». кейс все-таки проблемный. модель и её мета — вещи неразрывные.
Это не проблемный кейс, а твоё банальное незнание. В WebAPI ты можешь свободно использовать валидацию: http://codearticles.ru/articles/2232




var response = ControllerContext.Request.CreateResponse(HttpStatusCode.Created);
response.Headers.Location = new Uri(Request.RequestUri, "/api/data/" + (value.Id + 1));
return response;
}

P.S. Учи матчасть.

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