Учебник по веб-сервисам для разработчика WinForms?

Question

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

Я читал о различных вариантах (XML / SOAP против JSON, REST против ... ну, на самом деле я не знаю, как это называется и т. Д.), Но я не уверен, какие критерии в игре при принятии решения использовать один или другой. Очевидно, что я хотел бы использовать имеющиеся у меня инструменты (Visual Studio, .NET Framework и т. Д.), Не ограничивая себя только ориентацией на определенную аудиторию (т. Е. Написание службы таким образом, чтобы ее было трудно использовать). например, из клиента Windows Mobile / Android / iPhone).

Для протокола, на данный момент я планирую использовать WCF для разработки веб-сервисов, но я открыт для использования другого подхода .NET, если это целесообразно.

Я понимаю, что этот вопрос довольно открытый, поэтому он может быть закрыт, но вот некоторые вещи, которые меня интересуют:

1. Что нужно учитывать при выборе типа веб-службы (REST и т. Д.), Которую я намереваюсь написать? Можно ли (и если это возможно) перейти от одного подхода к другому?
2. Могут ли веб-службы быть написаны на основе событий? Как я уже сказал, я разработчик Winforms, поэтому я привык к объектам, вызывающим события, на которые я реагировал. Например, если у меня есть два клиента, подключенных к моему сервису, есть ли способ для меня «передать» информацию одному из них в результате действия другого? Если это возможно возможно, это целесообразно или я просто не думаю об этом правильно?
3. Какие механизмы аутентификации лучше всего работают для общедоступных служб? А что, если я планирую подключать к сервису разные типы ОС и клиентов? Существует ли общепринятый платформо-независимый подход?
4. В строке аутентификации это то, что я должен делать сам (аутентификация управляющих сеансов и т. Д.) Или это что-то должно обрабатываться на уровне платформы, и я просто определяю, как именно это должно работать? Если это так, как я могу сказать, кто запрашивающий аутентифицировал себя как?

Я начал писать механизм аутентификации (простые комбинации имени пользователя и пароля, хранящиеся в базе данных, и соответствующую таблицу сеансов с ключом GUID) внутри моей службы и просто требовал, чтобы этот ключ передавался при каждой операции (кроме входа в систему, конечно), но я хочу убедиться, что я не изобретаю колесо здесь. Однако я также не хочу загромождать сервер кучей учетных записей пользователей компьютеров только для использования обычной аутентификации. У меня также сложилось впечатление, что для дайджест-аутентификации (и, конечно, Windows) требуется учетная запись пользователя компьютера (или AD).

Answer 1

1 -> REST быстрее, чем SOAP, так как (я думаю) использует нативно HTTP, но я не думаю, что он настолько безопасен. SOAP имеет больший вес, отправляя SOAP-пакеты вокруг заголовка, полезной нагрузки и т. Д.

2 -> Использование может использовать асинхронные вызовы, но вы можете обращаться с ними как с любым другим классом, хотя и без состояния.

3 -> В связи с природой наших общедоступных сервисов у нас есть собственный настраиваемый веб-сервис безопасности, и мы передаем объект кредит пользователя каждому методу, чтобы убедиться, что пользователь аутентифицирован и имеет разрешение. (это довольно простое решение, но проект сам по себе)

4 -> См. 3. Хотя я уверен, что вокруг вас должны быть какие-то фреймворки для фреймворков. Если в вашем домене есть все, я уверен, что вы можете настроить IIS для аутентификации этих пользователей.

Извините, это не очень подробный ответ, как я уже сказал, вы, вероятно, получите лучшие ответы, если разбите свой вопрос на 4 части.