С чего начать изучение программирования под WEB?

[yudjin]

День добрый. До этого писал только настольные приложения под Win (С++, C#, WinAPI). Встала задача разработки под вэб. Впринципе, наклепал корпоративный  сайтик, используя Web-Forms (ASP.NET), ORM - LINQ, даже писал сервисы для Silverlight... Но понимаю, что ничего не знаю про "клиент/сервер (web)", спецификации протокола (HTTP, SOAP, REST), хотя писал под них. С мануалов. Быдлокодерствовал, если кратко.
Вопрос - посоветуйте профессиональную литературу по теории вэб-программирования. Начинал читать непосредственно про ASP.NET, ASP.MVC, WCF - там только вкратце упоминается о протоколах HTTP, как буд-то бы читатель их уже знает. Не спецификации же изучать? Хотя помню, как на 3м курсе под линухом осуществляли передачу данных по HTTP - там еще про "зомби"-процессы расказывали и "демонов"..

[Золотая Лань]

«программирование под веб» — это слишком много всего.
Вы уж определитесь, чего именно вам хочется.

И ещё: если хотите действительно приобщиться к вебу, то выходите из религии «майкрософт — наше всё», она вам добром не послужит на этом поприще.

[yudjin]

клиент/сервер - почему теряется состояние, почему трудно перейти от программирования настольного ПО к интернет-ориентированному?
GET / POST
Сессии
Основы, но не CSS, XML, HTML

Оффтоп

выходите из религии «майкрософт — наше всё», она вам добром не послужит на этом поприще.

Уж кому, как не нам, двигать прогресс, так нет: якорями упираемся в прошлый век.

Наверное, в Холи-вары? Можно оставаться с MS с учетом понимания того, что происходит за кулисами. Хорошее понимание C# - результат работы с C++ & WinAPI, LINQ - сам писал до этого классы/обертки с репозиториями. Почему бы теперь не брать готовые инструменты, которые сокращают сроки разработки?

[Dimka]

yudjin, а какова прикладная задача?

[Finch]

yudjin, Не играйся со шрифтами. Шрифт 6 pt только глаза ломать.

[yudjin]

yudjin, а какова прикладная задача?

Расширился круг пользователей. Раньше писал только внутри-корпоративные настольные ПО (ничего сложного, пищалки-считалки), теперь начальство хочет данные наружу толкать за денюжку. Для меня это - шанс освоить еще парочку технологий. Но хочу именно освоить, а не иметь поверхностные представления. Только что завершил первых два модуля (CMS и аудит клиентов)... Ничего нового не узнал про вэб. ASP.NET WebForms все это тщательно скрывают. Чувствую себя обманутым. Начал читать про  MVC - стало пояснее в  некоторых местах. Понравилось, больше контроля, гибкости. Но все равно, про взаимодействие между клиентом и сервером ничего не известно.
Написал пару WCF-сервисов для клиентской части. да, работают. Как - неизвестно. Читаю про WCF (O'Reali издательство) - там тоже ни слова о протоколах RESP. А между тем, я под них программил (по мануалам)
Посоветуйте, кто что может качественного
Итак, основной вопрос - повторюсь - с чего начать изучать вэб-ориентированную разработку. Поверхностные знания есть, хочется фундаментального.

1. клиент/сервер - (н-р, почему теряется состояние)
2. почему трудно перейти от программирования настольного ПО к интернет-ориентированному?
3. методы передачи данных GET / POST
4. Сессии

Пока не нашел книги, где было бы это описано.

[RXL]

По сути идет обработка события - запроса HTTP-клиента. Имеются параметры запроса: метод HTTP, URL: протокол, имя сервера, путь, строка запроса (обычно среда уже делит ее на части-параметры), данные POST (если есть). По этому делу почитай стандарт HTTP 1.1 (RFC 2616). Методов HTTP много, но в Web обычно ограничиваются тремя: GET, HEAD (Аналог GET, но клиенту возвращается только заголовок. Используется все реже и реже, т.к. есть другие механизмы.) и POST.
Любой процесс (или поток - зависит от сервера) по может последовательно обработать запросы от разных HTTP-клиентов. По этому контекст приложения между вызовами не сохраняют, т.к. это просто не имеет смысла. Чтобы это компенсировать, надо различать клиентов. Обычно для этого используют Cookie (см. описание HTTP), где передают некоторый идентификатор, по которому сервер восстанавливает контекст сессии и по окончанию обработки запроса должен его сохранить или удалить из хранилища.

Чтобы прочувствовать весь HTTP, нужно программировать с интерфейсом CGI, но это тот еще геморрой. Лучше попробуй PHP - он дает базовый сервис, но и частично позволяет взаимодействовать с заголовками HTTP напрямую.

[Dimka]

RXL, в плане работы напрямую ASP.NET ничем не хуже. Есть Request.InputStream и Response.OutputStream - можно писать, что угодно (Недавно я с их помощью вручную серверную часть AJAX реализовывал.)

Для меня это - шанс освоить еще парочку технологий. Но хочу именно освоить, а не иметь поверхностные представления.

Лично я усматриваю в этом противоречие. Знание протокола SOAP не прибавит умения пользоваться WCF.NET, а умение пользоваться WCF.NET, как ты сам убедился, не требует знания.

Если смотреть по уровням, то:
- в основе лежит TCP/IP, понятие соединения/сессии, сокета и т.п.;
- синхронная и асинхронная модели обмена сообщениями;
- сериализация/десериализация данных и понятие RPC;
- ссылочная целостность, адресация объектов в сети (по идентификаторам, а не по адресам в машинной памяти) - плавный переход к реляционным (реляционные СУБД), иерархическим (XML) и сетевым (URI) моделям данных.

И больше ничего там нет. Все эти HTTP, SOAP, WSDL - это лишь соглашения о форматах передаваемых данных (реализованные в библиотеках и не требующие программирования вручную), т.е. к сути дела относятся мало.

А все прочие надстройки: модель страниц и элементов управления ASP.NET, конфигурация WCF.NET, библиотеки скриптов для DHTML - это всё обычное программирование, на мой взгляд, не имеющее ничего веб-специфичного, просто в основе лежит какой-то свой framework, как и в любой другой "технологии". В общем-то ты в этом и убедился, почему-то посчитав себя "обманутым".

[Вад]

Чтобы прочувствовать весь HTTP, нужно программировать с интерфейсом CGI, но это тот еще геморрой. Лучше попробуй PHP - он дает базовый сервис, но и частично позволяет взаимодействовать с заголовками HTTP напрямую.

В моём случае, чтобы сформировать общую картину, как это всё работает, было достаточно повозиться с написанием своего клиента для http-proxy. Для тестирования понадобилось поднимать свои прокси (3proxy, squid) и прогонять запросы так и сяк (в случае кэширующего и в случае метода CONNECT) - так или иначе, возня на таком уровне "погружает" в работу http-серверов (вплоть до того, чтобы telnet-ом на сервера походить, запросы ручками повбивать), хотя весь стандарт целиком до последней буквы я не изучал.

[RXL]

Вад, это разные стороны - у тебя клиент, а CGI используют серверные приложения.

[Вад]

Вад, это разные стороны - у тебя клиент, а CGI используют серверные приложения.

Это разные стороны одного и того же, ведь изначально вопрос был про HTTP? От http к CGI уже один шаг остаётся.

[RXL]

У каждой стороны свои особенности и проблемы. Клиентская часть, как правило, значительно проще серверной: клиент знает, что делает, а сервер только предполагает, что делает клиент.

[Dimka]

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

Хотя те же браузеры обычно лишь угадывают содержимое, приходящее от серверов - не все следуют strong-вариантам стандартов.

По поводу CGI... Это ж обычная программа, имеющая stdin, из которого читает, и stdout, в который пишет... Чего в нём такого... Остальные сложности программист создаёт себе сам своими руками.

[RXL]

Дим, корпоративных решений это тоже касается. Особенно если используются разные браузеры. Решения типа "только IE6" не я считаю профессиональными.

В CGI ничего "такого" нет. Но есть прямая работа с тем что есть: заголовки и методы HTTP через переменные окружения, POST/PUT через stdin, вывод заголовков (очень интересная область, хотя решается тоже не сложно) и контента в stdout, обработака предпочтений клиента в кодировках, языках, форматах и т.п.

[Dimka]

Решения типа "только IE6" не я считаю профессиональными.

"Кто девушку ужинает, тот её и танцует"... Если заказчик не хочет ничего другого и особо оговаривает, что тестирование и отладку под другие браузеры оплачивать не будет - это его выбор в условиях всей предоставленной ему информации. Любая глупость за ваши деньги. Назвался CIO - сам отвечай за свою технологическую политику.

обработака предпочтений клиента в кодировках, языках, форматах и т.п.

Согласен.

[RXL]

Помимо пресловутого "заказчика" есть "готовый" продукт, с доработкой за отдельное не маленькое бабло.

[Dimka]

RXL, продукт для заранее неопределённого круга пользователей, конечно, должен быть отлажен под все возможные среды.

[RXL]

Dimka, разработчики так обычно далеко не всегда считают...

[yudjin]

Спасибо, я получил ответы на мои вопросы Теперь ясно, каких (всех) знаний у меня не хватает в этой области.