Что такое код asp processntcrifloggedon

Содержание

Криптография в ASP.NET

Ранее вы узнали, как идентифицировать пользователей с помощью нескольких поддерживаемых механизмов аутентификации, и как реализовать авторизацию этих пользователей в своих приложениях. ASP.NET поддерживает такие развитые службы, как Membership API и Roles API, которые помогают реализовать эту функциональность.

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

В состав .NET входит многофункциональный интерфейс CryptoAPI, предназначенный для решения широкого диапазона криптографических задач — таких как создание хешей различного типа (MD5, SHA1 и т.п.) и реализация наиболее важных симметричных и асимметричных алгоритмов шифрования. А если этого недостаточно, то .NET Framework включает отдельные функции для защиты секретной информации на локальной машине или для каждого пользователя посредством полностью управляемых оболочек интерфейса Windows Data Protection API (DPAPI).

Шифрование данных: соображения конфиденциальности

Ранее было показано как использовать для защиты паролей с помощью методов класса FormsAuthentication. Благодаря хешированию, сохраняется контрольная сумма («отпечаток пальца») исходных данных, но не сами данные. В результате повернуть вспять процесс хеширования, чтобы восстановить исходные данные, возможности нет. Все, что можно сделать — хешировать новые данные и выполнить сравнение.

Подход, основанный на хешировании — наиболее безопасный способ проверки достоверности паролей. Однако он не слишком помогает, когда требуется защитить ценные данные, которые в будущем необходимо расшифровать. Например, при разработке приложения электронной коммерции, возможно, понадобится сохранять информацию о кредитной карте пользователя, чтобы использовать ее позже в заказах. При таком сценарии приложение нуждается в возможности извлечения этой информации. Здесь хеширование не поможет достичь того, что в действительности нужно.

Часто разработчики в такой ситуации сохраняют ценные данные в виде открытого текста. Они предполагают, что поскольку данные хранятся в защищенном месте на сервере, не имеет смысла брать на себя дополнительную работу по их шифрованию. Однако эксперты по безопасности знают, что это не так. Без шифрования злоумышленнику достаточно получить доступ к серверу всего на несколько минут или даже секунд, чтобы извлечь пароли или номера кредитных карт каждого заказчика.

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

Пространство имен Cryptography в .NET

Все необходимые классы для шифрования и расшифровки информации в приложениях можно найти в пространстве имен System.Security.Cryptography. Кроме того, там находятся все основные классы для создания различного рода хешей. Если вы обратитесь к дополнительной сборке System.Security.dll, то получите в свое распоряжение еще более совершенную функциональность обеспечения безопасности — такую как API-интерфейс для модификации Windows ACL (пространство имен System.Security.AccessControl), DPAPI и классы для создания кодов аутентификации на основе .

В таблице ниже описаны категории этих классов:

Категории классов безопасности из пространства имен System.Security.Cryptography

Пространство имен включает наиболее важные алгоритмы хеширования и шифрования, а также классы для создания цифровых подписей

Если нужно создавать криптографически строгие случайные числа, то вспомогательные классы для этого находятся в пространстве имен System.Security.Cryptography. Вспомогательные классы предназначены для взаимодействия с криптографической системой Windows (CryptoAPI)

В пространстве имен System.Security.Cryptography.X509Certificates находятся все необходимые классы для работы с сертификатами X509 и классы для доступа к хранилищу сертификатов Windows

Полную поддержку сигнатур XML и стандартов шифрования можно найти в пространстве имен System.Security.Cryptography.Xml. Классы в этом пространстве имен используются для шифрования и подписи документов XML в соответствии со стандартами, опубликованными консорциумом W3C

Платформа включает управляемую поддержку упакованных согласно CMS/PKCS сообщений непосредственно от вызовов неуправляемого кода. (CMS — Cryptographic Message Syntax (Синтаксис криптографических сообщений), a PKCS — Public-Key Cryptography Standard (Стандарт шифрования с открытым ключом).)

В веб-мире сертификаты X509 играют важную роль. Они устанавливают коммуникации SSL и выполняют аутентификацию с помощью сертификатов для защиты трафика между веб-сервером и его клиентами. Сертификат X509 — это двоичный стандарт инкапсуляции ключей для алгоритмов асимметричного шифрования вместе с сигнатурой специальной организации, издающей сертификаты (обычно такие организации называются центрами сертификации).

Для простых SSL-соединений доступ к хранилищу сертификатов не требуется. Но если в коде планируется обращаться к веб-службам или веб-приложениям, расположенным на другом сервере, который требует аутентификации сертификатом X509, то приложение должно прочитать сертификат из хранилища сертификатов Windows и добавить его к веб-запросу (или к прокси веб-службы) перед отправкой этого запроса. Для этой цели в пространстве имен System.Security.Cryptography.X509Certificates предусмотрено несколько классов:

X509Certificate и X509Certificate2

Эти классы инкапсулируют сертификаты X509. Они позволяют загружать сертификаты из разных хранилищ, таких как файловая система, и обеспечивают доступ к свойствам сертификата. Класс X509Certificate изначально появился в самых ранних версиях .NET Framework. Класс X509Certificate2 — это расширение класса X509Certificate, включающее ряд дополнительных методов и свойств.

X509Store

Этот класс предоставляет доступ к хранилищу сертификатов Windows, которое является местом, где Windows хранит все сертификаты. Для каждого пользователя Windows создает такое хранилище (доступное через StoreLocation.CurrentUser), а для машины поддерживает в точности одно хранилище (StoreLocation.LocalMachine). Пользовательские хранилища доступны только тем пользователям, для которых они созданы, в то время как хранилище машины содержит сертификаты, доступные всем пользователям, работающим на этой машине.

X509CertificateCollection

Это простой класс, предоставляющий коллекцию экземпляров X509Certificate и X503Certificate2, хранящих одиночные сертификаты. X509Store позволяет извлекать как список сертификатов, так и одиночные сертификаты, на основе одного из уникальных идентификаторов (таких как ключ субъекта сертификата, имя субъекта или хеш).

Прочитать сертификат из хранилища и присвоить его веб-запросу можно следующим образом:

В этом коде открывается персональное хранилище сертификатов локальной машины с использованием класса X509Store. Затем предпринимается попытка найти в этом хранилище сертификат с именем субъекта «CN=PROFESSORWEB». Здесь используется общий синтаксис именования, который, возможно, знаком по системам каталогов LDAP.

В Windows поддерживается несколько типов хранилищ сертификатов, которые называются . Хранилище локальной машины, например, доступно всем приложениям, запущенным с определенными привилегиями на этой локальной машине. Можно создать отдельное хранилище для каждой Windows-службы на машине, и каждый пользователь может иметь отдельное хранилище сертификатов. Сертификаты безопасно хранятся в этих хранилищах.

В то время как хранилище локальной машины шифруется ключом, управляемым локальным центром безопасности данной машины, пользовательское хранилище шифруется ключом, который хранится в профиле пользователя. В пределах одного местоположения хранилищ Windows различает хранилища, используемые для разных целей. Наиболее важными хранилищами являются персональное («my») хранилище и .

Обычно хранилище «my» содержит все сертификаты, используемые приложениями (и пользователями, если речь идет о пользовательском хранилище), в то время как хранилище Trusted Root Certification Authorities содержит сертификаты для центров, издающих сертификаты. Примером известного центра сертификации, у которого можно приобретать сертификаты, является VeriSign.

Если сертификат помещается в хранилище Trusted Root Certification Authorities, то тем самым утверждается, что любой сертификат, изданный этим центром, заверен системой и потому может использоваться любым приложением безо всяких опасений. Другие сертификаты по умолчанию не являются доверенными, и потому помечаются специальным флагом. Конечно, для таких критичных операций, как аутентификация или настройка SSL на сервере, необходимо применять только допустимые сертификаты, изданные доверительным центром, поскольку любые другие сертификаты представляют потенциальный риск нарушения безопасности.

В веб-приложениях ASP.NET должно использоваться либо хранилище локальной машины, либо хранилище учетной записи службы (представляющее собой пользовательское хранилище служебной учетной записи, от имени которой запущена системная служба Windows). Таким образом, представленный выше код открывает хранилище с флагом StoreLocation.LocalMachine. Вторым возможным флагом для этой опции является StoreLocation.CurrentUser, который открывает хранилище текущего пользователя или учетной записи службы Windows. Поскольку данный сертификат — это сертификат «использования», он читается из персонального хранилища.

Все сертификаты, находящиеся в хранилище, можно просмотреть, открыв консоль управления Microsoft Management Console и затем запустив оснастку Certificates (Сертификаты), как показано на рисунке ниже:

Чтобы открыть эту консоль, запустите консоль управления (mmc.exe) и выберите пункт меню File Add/Remove Snap In (Файл Добавить или удалить оснастку). В открывшемся диалоговом окне выберите Certificates в списке доступных оснасток и добавьте ее в список выбранных. Выберите хранилище, которое хотите отобразить в оснастке. После этого закройте диалоговое окно, и оснастка Certificates отобразит в консоли управления все хранилища и сертификаты в этих хранилищах для выбранной учетной записи.

Для создания тестовых сертификатов служит команда makecert.exe. Например, следующая команда создает сертификат в персональном хранилище на локальной машине:

После получения из хранилища сертификат можно использовать при отправке запросов по SSL на сервер, который требует аутентификации с помощью сертификатов:

Для того чтобы приведенный код компилировался, понадобится импортировать пространство имен System.Net в файл кода. Этот код полезен в ситуации, когда приложению нужно извлекать данные из другого веб-приложения или отправлять данные другому веб-приложению с использованием HTTP-запросов GET либо POST, а другое приложение требует аутентификации с помощью сертификатов.

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

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

За дополнительной информацией о генераторе случайных чисел обращайтесь в документацию Windows по поставщику Cryptographic Service Provider, поскольку этот класс представляет собой оболочку встроенной реализации.

CORS и кросс-доменные запросы

Начало работы с CORS

По умолчанию в целях безопасности браузер ограничивает ajax-запросы между различными доменами. Однако нередко возникает ситуация, когда необходимо выполнять запросы из приложения с одного адреса (или домена) к приложению, которое размещено по другому адресу. Для этого нам надо использовать технику, которая называется CORS (Cross Origin Resource Sharing).

В начале создадим новый проект ASP.NET Core по типу Empty:

Этот проект будет получать запросы от других приложений и отправлять им ответ. Для этого изменим его класс Startup следующим образом:

Для работы с CORS необходим пакет Microsoft.AspNetCore.Cors . В проекте ASP.NET Core 2.0 этот пакет уже имеется по умолчанию.

Для подключения сервисов CORS в приложение в методе ConfigureServices вызывается метод services.AddCors() .

Чтобы задействовать CORS для обработки запроса в методе Configure вызывается метод UseCors() . Для настройки конфигурации этот метод использует делегат, в который передается объект CorsPolicyBuilder . И с помощью этого объекта можно выполнить настройку CORS.

С помощью метода AllowAnyOrigin() мы указываем, что приложение может обрабатывать запросы от приложений по любым адресам.

В итоге всем подключенным клиентам данное приложение будет отправлять строку «Hello World!».

Для тестирования создадим второй проект также ASP.NET Core 2.0 по типу Empty. Определим во втором проекте следующий класс Startup:

Здесь мы будем работать только со статическими файлами. В частности, определим во втором проекте в папке wwwroot html-страницу index.html , которая будет загружаться по умолчанию:

В данном случае по нажатию на кнопку будет выполняться ajax-запрос к первому приложению, который, в моем случае, будет запускаться по адресу «http://localhost:49352/». Полученный от первого приложения ответ будет загружаться в блок

Запустим оба проекта и во втором приложении нажмем на кнопку, чтобы получить ответ от первого приложения:

Что такое Web API?

Web API – новая исполяющая среда веб-приложения, построенная на уроках и паттернах, одобренных в ASP.NET MVC. Используя простую парадигму контроллеров, Web API позволяет разработчику создавать простые Web API веб-службы с небольшим по объему кодом и конфигурацией.

Вы можете задать очень разумный вопрос: почему нам нужен новый фреймворк веб-служб? Не входит ли уже в стек разработки компании Microsoft популярная и широко совместимая технология Simple Object Access Protocol (SOAP) (простой протокол доступа к объектам)? И не существовали ли ASMX веб-службы с тех самых пор, как был выпущен ASP.NET? И не поддерживает ли уже Windows Communication Foundation (WCF) самую гибкую и расширяемую архитектуру веб-служб? Веб-службы являются повсеместными, и разработчики понимают их. Почему Web API?

Почему Web API?

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

  • Я верю в то, что существует лучший способ создания веб-служб.
  • Я верю, что веб-службы могут быть простыми и что WCF слишком сложен.
  • Я верю, что в будущем мне нужно будет поддерживать больше HTTP клиентов.
  • Я верю, что основных веб-технологий таких, как GET , POST , PUT и DELETE , достаточно.

Если вы все еще читаете, то мы продолжим обзором того, чем Web API отличается от других фреймворков. Затем мы расширим приложение «Guestbook» таким образом, чтобы поддерживались HTTP веб-службы для существующих экранных функций, с целью продемонстрировать вам, как просто использовать Web API.

Чем Web API отличается от WCF?

ASMX веб-службы на протяжении многих лет поддерживали SOAP веб-службы поверх HTTP, но они не без труда поддерживали более простые веб-службы, которым не нужно было наличие способности взаимодействовать и, таким образом, для них не нужен был SOAP. WCF занял место ASMX как самый последний и лучший способ создания веб-служб на стеке .NET. WCF службы для конечных точек HTTP похожи на следующий код.

Листинг 24-1: Для WCF служб требуется интерфейс, класс и множество атрибутов

Строка 2: Интерфейс определяет службу

Строка 4: Атрибуты определяют операции

Строка 11: Отдельный класс реализует логику службы

В рамках WCF каждая веб-служба определяется с помощью интерфейса, который определяет соглашение. Каждый метод, отмеченный OperationContract , определяет операцию в SOAP конверте WCF службы. Наконец, класс, который реализует интерфейс службы, реализует код и логику.

Запуская эту службу в Visual Studio, вы можете использовать тестовый клиент WCF для того, чтобы увидеть запрос и отклик операции GetData , как это продемонстрировано на рисунке 24-1.

Рисунок 24-1: Тестовый клиент WCF может помочь вам протестировать SOAP веб-службу с помощью WCF.

В рамках отрасли многие разработчики прилагают усилия для упрощения WCF HTTP веб-служб. Многие говорят о RESTful-стиле (Representational State Transfer – репрезентативная передача состояния), который был введен для того, чтобы обозначать использование простейших HTTP веб-служб без всяких украшательств.

ASP.NET Web API использует понятие обычного MVC контроллера и базируется на нем для того, чтобы создать для разработчика простое и продуктивное событие. Web API оставляет SOAP в истории как средство, которое используют приложения для взаимодействия. На сегодняшний момент, из-за повсеместного использования HTTP, большинство рабочих сред и систем программирования поддерживают основные принципы HTTP веб-коммуникации. В связи с тем, что вопрос совместимости решается другими способами, SOAP может быть отодвинут в сторону возрастающими технологиями наследования, а разработчики могут быстро создавать простые HTTP веб-службы (web APIs) с помощью ASP.NET Web API фреймворка.

Примите во внимание различие между кодом, который используется для создания самых простых SOAP веб-служб в листинге 24-1, и следующим кодом, который реализует те же самые функции.

Листинг 24-2: Web API обладает очень простым стилем программирования с ApiController

Строка 4: Базовый класс разрешает основную функциональность

Строка 7: Простые методы определяют операции

Первое отличие, которое вы должны были заметить, – это то, что количество строк кода в данном примере меньше, поскольку отсутствует необходимость в конкретном классе, а также в интерфейсе. Простое наследование от ApiController разрешает функциональность, необходимую для объявления метода в виде операции.

Возврат значения в рамках Web API схож с использованием WCF, но результат совершенно другой. Вы можете увидеть результат, запуская проект в Visual Studio и тестируя его с помощью веб-браузера. Помните, что одним из основополагающих убеждений, касающихся Web API, является тот факт, что веб-службы могут быть простыми. Перейдите с помощью Internet Explorer по адресу http://localhost:/api/values/43 , содержащий средства разработки (нажмите F12 ). На рисунке 24-2 продемонстрировано, что получится в результате.

Рисунок 24-2: Используются HTTP заголовки вместо SOAP конверта.

Вместо того чтобы возвращать SOAP XML , как это делается в WCF, используется более простой формат, JavaScript Object Notation (JSON). Этот формат силен в передаче единичных значений, а также структур сложных объектов. Поскольку язык JavaScript понимает этот формат, jQuery может принимать этот тип данных для использования в AJAX вызовах.

Теперь, когда вы увидели отличие WCF от Web API, давайте начнем добавлять некоторую интересную функциональность поверх приложения «Guestbook» из главы 2.

Нотация ARIS Information Flow

Нотация Information Flow является аналогом нотации DFD (см. ниже) и используется при построении схем потоков данных или документов между функциями бизнес-процессов предприятия, как показано на рис. 6.

Простота нотации ограничивает области ее полезного применения. Основными объектами нотации являются «Function» (используется также при построении моделей бизнес-процессов) и «Information Flow» — информационный поток (рис. 7).

При построении моделей бизнес-процессов сначала может быть построена модель eEPC, а затем, с использованием определенных в процессе функций, — модель информационных потоков.

Нотации, поддерживаемые BPwin 4.0

Не нашли то, что искали? Воспользуйтесь поиском:

Лучшие изречения: Только сон приблежает студента к концу лекции. А чужой храп его отдаляет. 8813 — | 7525 — или читать все.

188.64.174.135 © studopedia.ru Не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования. Есть нарушение авторского права? Напишите нам | Обратная связь.

Отключите adBlock!
и обновите страницу (F5)

очень нужно

asp.net core. Возвращать статус код 401 если требуется авторизация для доступа

Есть у меня такой код:

Хочу сделать так, чтобы при попытке обратиться к методу Current неавторизованному клиенту вместо представления выдавало статус код 401. Сейчас возвращает либо странице по умолчанию, либо код 404, если такой страницы не установлено в настройкай маршрутизации. Нужно чтобы этот код возвращался для всех методов, помеченных [Authorize] .

Код класса Startup :

update

Сделал следующий костыль: добавил контроллер AccountController с методом Login , который всегда возвращает UnauthorizedResult . Должен же быть адекватный способ решить мою проблему.

ASP.NET — что это такое?

По всей видимости, рядовые пользователи, использующие компьютеры исключительно для повседневных нужд или в сфере развлечений, с таким понятием, как ASP.NET, сталкиваются вряд ли. Зато веб-разработчики всех уровней подготовки знают эту платформу достаточно хорошо, хотя некоторые из них и считают, что она, если можно так сказать, морально несколько устарела. Тем не менее стоит сделать небольшой экскурс в историю создания и развития технологии ASP.NET. Что это такое, многим рядовым пользователям станет понятно после прочтения ниже предлагаемого материала. При этом попытаемся отталкиваться от самых простых терминов, не особо вдаваясь в механизмы функционирования этого инструмента, чтобы каждый желающий мог сообразить, о чем, собственно, идет речь.

ASP.NET: что это такое?

И для начала остановимся на самом инструментарии. Вообще, считается, что ASP.NET является достаточно мощным инструментом для быстрого создания веб-приложений, который входит практически во все известные на сегодня версии платформы Microsoft .NET Framework.

Сам же инструментарий содержит специализированные средства в виде веб-сервисов, программной инфраструктуры и модели программирования.

Многие считают, что описываемая технология является некой наследницей ASP. В чем-то сходство, безусловно, есть, и именно поэтому, как считается, многие программисты могут с легкостью перейти с устаревшей платформы на использование более новой. Однако на самом деле различия между этими двумя средами более существенны, что особо сильно проявляется в организации внутренней структуры среды разработки и обеспечения безопасности. Несмотря на вроде бы кажущиеся современные подходы к созданию веб-страниц и приложений, которые заложены именно в этой платформе, многие программисты относятся к ней с явным недоверием, предпочитая средства PHP или что-то подобное. Некоторые отзывы свидетельствуют о том, что не спасает ситуацию даже улучшенная среда разработки ASP.NET Core. Так ли это, далее и попробуем выяснить.

Для чего используется ASP.NET на практике?

Но это все были общие фразы. Рядовому пользователю нужно знать, какой практический смысл в использовании такого инструментария. В самом простом случае ASP.NET для профессионалов является весьма неплохим средством для быстрого создания динамических веб-страниц, которые существенно отличаются от статических (ASP). Иногда и включаемые в содержание HTML-страниц веб-сервисы тоже можно достаточно просто создать на основе инструментария ASP.NET.

При всем этом нужно четко понимать, что все это очень сильно взаимосвязано именно с платформой Microsoft. NET Framework и работает исключительно в исполняемой среде (CLR Environment) на основе компилируемых языков. Чтобы было понятнее, попробуем посмотреть, что собой представляют статические и динамические страницы, а также особое внимание уделим вопросам безопасности.

Основные отличия динамических веб-страниц от статических

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

Если используется статическая страница, созданная «вчера», сегодня она уже будет устаревшей. А вот на динамической странице счетчик курса как раз и будет изменяться. Естественно, это только самый простой пример, поскольку технология на самом деле гораздо сложнее. К тому же, если вы уже заметили, при создании страниц и сервисов такого типа можно отметить и то, что в некотором смысле они являются самообновляемыми, благодаря наличию встроенных модулей, отслеживающих изменение того или иного параметра.

История создания

Первые упоминания об ASP.NET относятся к 1997 году, когда корпорацией Microsoft была реализована первая версия сервера IIS, что касалось исследований возможности своеобразного отделения содержания от оформления с целью написания, так сказать, «чистого» кода. Изначально проект носил название XSP, но что значила литера «Х» в сокращении, для многих до сих пор остается загадкой. Но тут нужно понимать, что сама технология базировалась в то время на запатентованной компанией Sun Microsystems общей среде программирования Java, поэтому нет ничего удивительного в том, что и сама платформа была написана именно на этом языке. зато с выходом исполняемой среды CLR (Common Language Runtime) и фреймворка .NET исходные принципы стали совершенствоваться, что и привело в конечном итоге к появлению инструментария ASP.NET, которым, невзирая на лица, пользуются многие современные программисты, кто бы там что ни говорил об устаревании платформы.

Принципы использования и безопасности

Что касается основных составляющих данной платформы, она позволяет писать «чистые» коды на любом языке программирования, входящем в состав фреймворка .NET (например, C#, J#, Script .NET, VB .NET и др.). При этом частично реализация исполняемого кода в процессе формирования страницы возложена на так называемую абстрактную программную модель Web Forms. Кроме того, при использовании IIS-авторизации в ASP.NET существенно повышается и безопасность взаимодействия сервера и клиента на основе протокола HTTP.

Применение архитектуры Membership API позволяет управлять даже данными пользователей из других источников вроде SQL Server или Active Directory. Сама же аутентификация производится либо за счет специальных форм, либо прямо через Windows IIS.

Преимущества перед ASP

В смысле превосходства над своей предшественницей эта платформа действительно имеет ряд неоспоримых преимуществ. Так, например, ускорено выполнение компилированного кода, а все ошибки исправляются еще на стадии первичной разработки, улучшена обработка ошибок в готовой программе, быстрая разработка веб-приложений стала возможной за счет использования множества выделяемых пользовательских шаблонов, библиотек классов и элементов управления, появилась возможность написания исходного кода на любом языке, поддерживающем .NET и т. д. Кроме того, отдельно можно отметить, что теперь стало возможным кэшировать страницу целиком или частично для увеличения производительности и скорости ее загрузки в браузерах, использовать master-страницы и расширяемые модели событий, элементы управления и обработки запросов, а также применять встроенную поддержку AJAX.

ASP.NET Core

Эта ветвь в разработке основной платформы, по сути своей, сохранила те же принципы, которые был заложены в ASP.NET. Что это, с точки зрения улучшений?

Только то, что Core является практически полным аналогом ASP.NET, но с открытым исходным кодом и базируется на паттерне MVC. Кроме того, сама платформа стала более унифицирована по отношению к другим приложениям, отпала необходимость жесткой привязки к System.Web.DLL и IIS, и в ней появился собственный встроенный инструментарий для обеспечения внедрения зависимостей. А вот унификация позволила оптимизировать использование метода Main и запуск веб-части приложений.

Связь между ASP.NET и Framework

Как уже было сказано выше, ASP.NET имеет достаточно строгую привязку к основному фреймворку, что впервые было замечено при выходе платформы версии 1.0. Сам фреймворк выступает в качестве своеобразного средства стандартизации обращения к вызовам. В свою очередь, исполняемая среда CLR дает возможность использовать единый набор сервисов, вне зависимости от применяемого языка программирования.

Некоторые нюансы установки

Что касается установки платформы и ускорения разработки веб-приложений на основе .NET, большинство специалистов рекомендует для начального ознакомления устанавливать ASP.NET версии 2.0. Эта модификация может использоваться практически во всех десктопных и серверных версиях Windows с сопутствующими сервис-паками, начиная с Windows 2000. Но сами готовые страницы желательно размещать исключительно на Windows Server.

Можно ли обойтись без ASP.NET?

Как считается, установка ASP.NET не является необходимой при использовании Visual Studio .NET 2005 года выпуска и выше.

В этом наборе имеется специальный компонент Visual Web Developer Express Edition, для которого достаточно наличия только основного фреймворка .NET. Системные требования выглядят весьма скромными (ЦП 600 МГц 128 Мб ОЗУ), не говоря уже о том, что на установку всех компонентов, включая документацию, потребуется порядка 1,3 Гб свободного места на диске, но в процессе инсталляции VWD самостоятельно догрузит из интернета еще около 120 Мб.

Access control. Information flow security.

Related documents
Add this document to collection(s)

You can add this document to your study collection(s)

Sign in Available only to authorized users

Add this document to saved

You can add this document to your saved list

Sign in Available only to authorized users

Products
Support

Make a suggestion

Did you find mistakes in interface or texts? Or do you know how to improveStudyLib UI? Feel free to send suggestions. Its very important for us!

Разработка ASP.NET 5 веб-приложений с Visual Studio Code

Введение

10 лет назад трудно было вообразить, что разработка ASP.NET веб-приложений вне интегрированной среды разработки Visual Studio .NET буде возможна. Но в прошлом году произошли изменения. В апреле 2014 года на конференции разработчиков (Build) Microsoft анонсировал запуск нового легкого кросс-платформенного кодового редактора для разработки современных веб-приложений под именем Visual Studio Code.

Visual Studio Code

Visual Studio Code свободна для скачивания с официального сайта. Работаете ли Вы на Linux, Mac или Windows – не имеет значения. Вы можете скачать и запустить VS код на своей платформе.

Установка Visual Studio Code довольно проста, но если Вы застрянете, то всегда можете просмотреть документацию по установке.

Visual Studio Code является просто редактором кода на файловой основе и не имеет всех преимуществ полной интегрированной среды разработки Visual Studio .NET. Он легче по дизайну. Тем не менее, у редактора есть множество особенностей, которые поддерживают такие технологии, как IntelliSense для дополнения кода, Peek Definition для быстрого взгляда на функциональный код без навигации, реорганизацию кода и прочие. Visual Studio Code также поддерживает множество языков, например CoffeeScript, F#, Go, Jade, Java, Handlebars, Powershell и Python, для примера. Вы можете проверить языковую поддержку здесь.

Также Visual Studio Code способен поддерживать такие среды выполнения, как ASP.NET 5 и Node.JS. Если Вы их используете для веб-разработки с Microsoft Stack, можете быть уверенны, что ASP.NET 5 (новая версия ASP.NET) сейчас поддерживает кросс-платформенную разработку. Это значит, что можно разрабатывать ASP.NET-приложение в среде Linux, Mac или Windows так же, как и запускать его в любой из них. И Вам даже не нужно иметь интегрированную среду разработки Visual Studio .NET, чтобы сделать это.

Visual Studio Code – это все, что вам нужно, чтобы начать работать с ASP.NET 5, и это здорово!

Установка ASP.NET 5 & DNX (среды выполнения .NET):

ASP . NET 5 был построен с нуля, чтобы убедиться, что он придерживается современной парадигмы веб-приложений, и что приложения, разработанные с его помощью являются «облачными». Ключевыми аспектами ASP . Net 5 явля ются гибкость и модульность – он предлагает минимальные накладные расходы и позволяет нам выбирать только то, что мы хотим в рамках нашего веб-приложения.

DNX расшифровывается как Dot Net eXecution Environment.

Что такое Yeoman?

Если Вы работали в интегрированной среде разработки Visual Studio .NET, Вам будет интересно: «Есть ли здесь File > New > ASP.NET шаблон проекта?» Visual Studio Code является редактором кода на файловой базе, так что Вы можете просто открыть файл и начать редактирование. Кроме того, нужны поддерживающие средства, чтобы работать с исполняемым шаблоном ASP.NET.

Yeoman является популярным консольным инструментом для автоматического построения структуры проекта, а также обеспечивает базовым ASP.NET шаблоном для старта. Yeoman может быть установлен с помощью NPM, но для начала надо установить Node . JS .

Если у Вас нет Node в системе, можете установить его. Кроме Yeoman , Вам также нужны другие поддерживающие средства, такие как генератор ASP . NET , исполнитель задач Grunt и Bower . Вы можете выполнить это за одну команду. В командной строке набрать следующую команду и нажать enter:

npm install –g yo grunt-cli generator-aspnet bower

Теперь Вы можете строить веб-приложения.

Создание веб-приложения

Разберем пошагово, как построить структуру проекта нового ASP.NET 5 веб-приложения.

1. Откройте командную строку и перейдите в папку, где Вы хотите создать свое новое веб-приложение.

2. Введите в командную строку следующую команду:

3. Yeoman отобразит варианты приложений для генератора aspnet. Возможные варианты:

  • консольное приложение
  • веб-приложение
  • основное веб-приложение (без членов/аутентификации)
  • веб-приложение API
  • Nancy ASP.NET приложение
  • библиотека классов
  • тестовый проект Unit

Выберите сейчас основное приложение. Используйте клавиши со стрелками для выбора опции и нажмите enter.

4. Дальше нам нужно назвать веб-приложение. Используем HelloWorld как имя нашего образца ASP . NET 5 веб-приложения. Введите имя и нажмите enter. Yeoman построит структуру проекта.

5. Каталог, в котором будет создано наше веб-приложение будет иметь то же имя, что мы дали только что Yeoman . В данном случае — “ HelloWolrd ”.

6. Через командную строку откройте Visual Studio Code

7. Visual Studio Code запустит проект HelloWorld. Файлы в проекте будут отображаться в окне Проводника.

8. В редакторе Visual Studio Code выберите View > Command Palette option
и в командной палитре введите следующую команду:

dnx: dnu restore — (HelloWorld)

Выше написанная команда restore устанавливает нужные NuGet пакеты, необходимые для запуска веб-приложения. Она запустит командную строку, куда будут загружаться все пакеты. После выполнения будет получено сообщение, что загрузка завершена.

Запуск веб-приложения

Теперь, когда мы успешно создали веб-приложение, пришло время запустить его и посмотреть на результат.

1. В Visual Studio Code откройте Command Palette, выбрав View > Command Palette. Введите следующую команду для запуска приложения:

dnx: kestrel -(HelloWorld,Microsoft.AspNet.Hosting—server Kestrel–config hosting.ini

Примечание: Когда Вы начинаете набирать команду, командная палитра подскажет Вам полную команду в списке. Вы можете выбрать команду из списка и команда будет выполнена.

2. Откройте браузер и перейдите по ссылке http://localhost5000

Мы только что создали ASP.NET веб-приложение вне интегрированной среды разработки Visual Studio. Фактически, в настоящее время ASP.NET больше не только в Windows. Мы переходим на кросс-платформу – как с точки зрения разработки, так и размещения.

Интеграция Telerik UI для набора ASP.NET MVC

Teleric предлагает пользовательский интерфейс, известный как UI для ASP.NET MVC. Он произошел от Kendo UI и предусматривает HTML-помощников, которых называют “Kendo UI wrappers.” Они упрощают работу с элементами управления Kendo UI и ускорят вашу разработку.

Представим пошагово добавление пользовательского интерфейса для ASP.NET MVC в наш проект:

1. Откройте файл project.json и в узле (“dependencies”) добавьте Kendo (в настоящее время доступна бинарная версия Kendo Mvc – 2015.2.805).

2. Дальше откройте Startup.cs и найдите метод “ConfigureServices”. Добавьте следующий фрагмент в метод.

//Register UI for ASP.NET MVC Helpers

3. Затем откройте

/Views/_ViewImports.cshtml и импортируйте пространство имен Kendo.Mvc.UI .

@using Kendo . Mvc . UI

4. Скопируйте Kendo UI ресурс с клиентской стороны. Для этого Вам нужно установить пакет Kendo UI Professional (Commercial Package). Его можно установить через Bower с помощью следующей команды:

bower install https://bower.telerik.com/bower-kendo-ui.git

Пакет Kendo UI Professional Bower размещается в частном git -хранилище и требует активировать аккаунт Telerik. Во время установки Вам предложат ввести пароль несколько раз.

Bower установит пакет Kendo UI Professional как “ kendo — ui ” в папку wwwroot / lib .

5. Дальше нам необходимо зарегистрировать скрипты Kendo UI и стили в

link rel =»stylesheet» href =»

link rel =»stylesheet» href =»

link rel =»stylesheet» href =»

6. Теперь давайте используем виджет Kendo UI в одном из видов. Мы будем использовать виджет Kendo UI DatePicker. Откройте

/Views/Home.Index.cshtml и добавьте следующий фрагмент:

@RenderSection(«scripts», required: false)

7. Запустите веб-приложение через dnx: kestrel команду, что мы использовали ранее. Результат представлен ниже.

Введение в ASP.NET Core¶

В данной теме представлены новые концепции в ASP.NET Core, и здесь рассказывается, как разрабатывать современные веб приложения.

Что такое ASP.NET Core?¶

ASP.NET Core — это кроссплатформенный фреймворк с открытым исходным кодом для создания современных облачных веб приложений. Приложения ASP.NET Core могут быть запущены под`.NET Core `__ или под полной версией .NET Framework. Фреймворк состоит из модульных компонентов, что дает вам гибкость при создании решений. Вы можете разрабатывать и запускать ASP.NET Core приложения под Windows, Mac и Linux. ASP.NET Core имеет открытый исходный код на GitHub.

Почему ASP.NET Core?¶

Первый предварительный релиз ASP.NET появился почти 15 лет назад как часть .NET Framework. С тех пор миллионы разработчиков использовали его для создания и запуска веб приложений, и теперь он обладает гораздо большими возможностями.

В ASP.NET Core произошло большое число архитектурных изменений, в результате чего фреймворк стал компактным и модульным. ASP.NET Core не основывается на System.Web.dll. Он основывается на наборе пакетов NuGet. Это позволяет вам оптимизировать приложение, чтобы оно включало только те пакеты NuGet, которые вам нужны.

С ASP.NET Core вы получаете следующие фундаментальные улучшения:

  • Единую историю для сборки веб UI и веб API
  • Интеграцию современных клиентских фреймворков и рабочих процессов разработки
  • Облачную конфигурационную систему
  • Встроенное внедрение зависимостей
  • Новый легкий модульный поток HTTP запросов
  • Возможность хостинга на IIS или хостинга в самом процессе
  • Встроенный `.NET Core`_
  • Конструкцию в виде пакетов `NuGet`_
  • Новый инструментарий, который упрощает разработку
  • Возможность кроссплатформенного запуска ASP.NET приложений под Windows, Mac и Linux
  • Открытый исходный код

Анатомия приложения¶

Приложение ASP.NET Core — это просто консольное приложение, которое создает веб сервер в своем методе Main :

Microsoft.AspNetCore.Hosting.WebHostBuilder` , который следует паттерну сборки для создания хоста веб приложения. У паттерна есть методы, которые определяют веб сервер (например, UseKestrel ) и класс для запуска ( UseStartup ). В примере выше используется веб сервер Kestrel, но мы можем указать и другие серверы. В следующем разделе мы подробнее рассмотрим UseStartup . WebHostBuilder предлагает много дополнительных методов, включая UseIISIntegration для хостинга на IIS и IIS Express и UseContentRoot для указания корневой директории контента. Методы Build и Run создают IWebHost , который будет хостить приложение, и оно начнет слушать входящие HTTP запросы.

Startup¶

Метод UseStartup для WebHostBuilder указывает класс Startup для вашего приложения.

В классе Startup вы определяете поток обработки запросов, а также здесь настраиваются все сервисы, необходимые вашему приложению. Класс Startup должен быть открытым и содержать следующие методы:

  • ConfigureServices определяет, используемые вашим приложением (например, ASP.NET MVC Core, Entity Framework Core, > Configure определяет связующее ПО в потоке запросов
  • См. Запуск приложения

Сервисы¶

Сервис — это компонент для общего пользования в приложении. Сервисы доступны благодаря внедрению зависимостей. ASP.NET Core включает в себя встроенный IoC контейнер, который по умолчанию поддерживает внедрение конструктора, но вы можете легко заменить его IoC контейнером по вашему выбору. В дополнение к преимуществу слабого связывания, DI делает так, что сервисы доступны всему приложению. Например, везде доступно логирование . См. Внедрение зависимостей (Dependency Injection) .

Связующее ПО¶

В ASP.NET Core сы составляете поток запросов, используя Связующее ПО (Middleware) . Связующее ПО ASP.NET Core выполняет асинхронную логику для HttpContext , а затем либо вызывает следующее связующее ПО в цепочки, либо напрямую обрывает запрос. Обычно для связующего ПО используется “Use”, принимая зависимость для пакета NuGet и вызывая соответствующий метод расширения UseXYZ для IApplicationBuilder в методе Configure .

ASP.NET Core предлагает богатый набор связующего ПО:

С ASP.NET Core можно использовать любое связующее ПО, основанное на OWIN. См. Open Web Interface for .NET (OWIN) .

Серверы¶

Хостинговая модель ASP.NET Core напрямую не слушает запросы — она полагается на серверную реализацию HTTP, чтобы передавать запросы приложению. Переданный запрос представляется как набор интерфейсов feature, которые приложение затем компонует в HttpContext . ASP.NET Core включает в себя кроссплатформенный веб сервер, Kestrel , который обычно запускается за производственным веб сервером, таким как IIS или nginx.

Корневая директория контента¶

Корневая директория — это основной путь к любому контенту, используемому в приложении, например, его представления и веб контент. По умолчанию корневая директория контента — это то же самое, что и основной путь приложения для выполняемого хостинга; альтернативу можно указать с помощью WebHostBuilder .

Корневая директория веб¶

Корневая директория веб (web root) — это директория для открытых статических ресурсов, таких как файлов css, js и файлов изображений. Связующее ПО статических файлов по умолчанию отрабатывает файлы только из этой директории (и поддиректорий). Путем директории является /wwwroot , но вы можете указать и другой путь с помощью WebHostBuilder .

Что такое код asp processntcrifloggedon

Самым актуальный способом создать REST сервис в стеке технологий Майкрософт на сегодняшний день является ASP.NET Web API. До того эта технология значилась как WCF Web API и больше по названию тяготела к WCF. Но уже тогда там использовались сходные походы как в ASP.NET MVC, включая роутинг (routing). До нее существовали такие вещи как WCF 4 REST, WCF REST Starter Kit 3.5. Их все еще можно встретить на старых проектах и stackoverflow пестрит вопросами о них. Но то что ASP.NET Web API используется на новых проектах, а некоторые старые конвертируются, чтобы его использовать – радует. Так как предшественники были хуже как в плане технологии (приходилось писать много boilerplating code), удобства использования так и документации.

В предыдущих постах были рассмотрены некоторые теоретические аспекты REST – теперь создадим простой REST сервис с помощью Web API и рассмотрим ключевые элементы такого сервиса.
Начать стоит с подключения NuGet packages (и/или установки ASP.NET MVC):

  1. Web API, в случае если хостимся в ASP.NET:AspNetWebApi
  2. Self-hosted Web API:AspNetWebApi.Selfhost
  3. HttpClient включая XML и JSON форматеры:System.Net.Http.Formatting
  4. JsonValue для навигации и манипуляции JSON:System.Json

В нашем случае, мы создадим просто сервис, который хостится на ASP.NET MVC, а также посмотрим на принцип создания интеграционных тестов к нему, которые будут поднимать self-hosted REST сервис в тестовом контексте. Акцент на Data access layer делятся не будет, если в процессе вам необходимо прикрутить DAL, например, с использованием Entity Framework Code First, то я писал об одном из возможных подходов раньше.

Перед тем как создавать такой сервис необходимо также понимать что использовать Web API стоит если есть тесная связка с веб-клиентом, если сервис содержит логику выходящую за рамки CRUD операций. Если же у вас сервис по сути своей поставщик данных, т.е. операции в основном CRUD, то лучше использовать WCF Data Services, так как там много вещей из коробки генерится под базу — и CRUD операции и нормальная поддержка OData и IQuerable (в ASP.NET Web API она ограничена), которые позволяют делать запросы к сервису и данным с помощью Uri и специального OData синтаксиса.

Итак преступим. Для начала создадим новый проект ASP.NET MVC4:

Изображение 1
Естественно темплейт (шаблон) для MVC 4 нагенерит нам типичную структуру ASP.NET MVC проекта (файл ValuesController я уже успел переименовать на DocumentsController). Отличие в дополнительном контроллере для Web API. По умолчанию это ValuesController, естественно его необходимо переименовать.

В нашем случае он стал DocumentsController. Из темплейта этот контроллер содержит операции заглушки для Get, Post, Put, Delete. В просто случае переопределим эти операции для DocumentsController и ресурса Document. Получится вот такой вот контроллер:

Это простой вариант, и здесь не используются фильтры для обработки сообщений или dependency resolvers. В свою очередь IDocumentRepository реализовано как простая заглушка и если дальше развивать тему с нормальным доступом к данным то реализацию можно подставить любую.
Теперь проверим операции. Это сделать можно используя Fiddler и правильно сформировав запрос. Например операция получения всех документов, используем адрес http://127.0.0.1:81/api/documents/. Используется стандартный роутинг из коробки:

Итак, запрос на http://127.0.0.1:81/api/documents/ должен вызвать метод IEnumerable Get() :

Так и есть, нам вернулся список в виде XML из двух элементов. Теперь попробуем content negotiation из коробки в действии. К тому же самому вызову добавим HTTP заголовок – Accept:application/json. Итак запрос:

Ответ ожидаем в Json:

Из коробки идут два стандартных форматера – XML и Json, но есть возможность добавлять свои.

Аналогичным образом будут работать остальные операции. Единственное попробуем еще запросить документ с недействительным идентификатором. Будем вызывать метод Document Get(string id) по адресу http://127.0.0.1:81/api/documents/9505a3b549b54881b3ed83fc19510534, где 9505a3b549b54881b3ed83fc19510534 – недействительный идентификатор, изменили последнюю цифру.

Ожидается ответ 404 NotFound. Результат запроса:

Вот таким вот образом можно создать и протестировать на работоспособность простенький REST сервис на базе ASP.NET Web API.

Основные концепты — ApiController

Так как мы имеем дело с REST сервисом. То из всего этого добра нас интересуют на начальном этапе контроллеры и роутинг. Контроллеры для Web API REST сервиса наследуются от от класса ApiController, который в свою очередь от интерфейса IHttpController. И ApiController несет с собой много добра, кроме конечно того что она автоматом распознается и выполняется. Из всего этого добра самое интересное являются свойства Request и Configuration.

Основные концепты – Routing (Роутинг)

При вызове операций с контроллера важный момент играет routing. Именно routing позволяет подсистеме WebApi связать Uri адрес и конкретную операцию из контроллера. Причем есть несколько вариантов — либо операция-action помечается атрибутом, либо используется договоренность именовать операции с префиксом – Http Verb. Например, в методе PostDocument – именно префикс Post позволяет сказать Web Api что эта операция связанна с Uri и вызывается по соответствующему адресу с HTTP Verb – POST.
Еще одним вариантом для того, чтобы помочь выделить среди методов контроллера операции, которые связанны с URL – использование атрибутов — HttpGet, HttpPut, HttpPost, или HttpDelete, каждый из них соответствует такому же HTTP Verb – GET, PUT, POST, DELETE. Для того, чтобы навесить на операцию больше чем один HTTP Verb, или операцию отличную от 4 базовых (GET, PUT, POST, DELETE), используется атрибут – AcceptVerbs. Использование атрибутов также дает возможность отказаться от конвенции именования методов, когда префиксом выступает HTTP Verb.

А для того чтобы избежать мапинга (mapping) метода как action используется атрибут NonAction без параметров.
Есть еще способ роутинга, когда каждый мапинг делается по средством атрибутов на метод, а не глобальным роутингом через Global.asax.cs, но о нем позже, так как он не стандартный. Хотя на этапе WCF Web API использовался именно он.

Routing по-умолчанию в Web API устанавливается как в методе RegisterRoutes на изображении 5 ниже. При использовании такого routing необходимо придерживаться конвенции именования методов в контроллере, когда каждый метод начинается с HTTP Verb префикса.

Ну и естественно важная часть маппинга – routing в Global.asax.cs:

Соответственно под роутинг «api//» подпадают URLs и примерные имена методов:
Можно также сделать роутинг по имени action. Он не создается по-умолчанию темплейтом проекта. Например:
В случае с таким роутингом необходимо использовать атрибуты HttpGet, HttpPut, HttpPost, HttpDelete или AcceptVerbs чтобы указать на какие методы мапить . В WCF WebAPI использовался роутинг с помощью атрибутов, его тоже можно прикрутить, но об этом отдельно.

Основные концепты — HttpResponseMessage, HttpRequestMessage

По сути это два спец класса которые используются достаточно часто. Они нужны для того чтобы иметь возможность оперировать запросом и ответом. HttpRequestMessage можно получить через свойство Request от ApiController (Изображение 6). Tак как Web API контроллеры всегда наследуются от ApiController, то его можно получить в середине любого из наших контроллеров. HttpRequestMessage позволяет нам управлять запросом, например извлекать из него данные из HTTP Body либо HTTP Headers которые нам нужны.

HttpResponseMessage можно создать, чтобы вернуть результат, либо просто Response код (Изображение 7), либо еще и с нагрузкой, запаковав в его свойство Content, нужный нам HttpContent, например для бинарных данных подойдет наследник от HttpContent – StreamContent. Из свойства Request можно вычитать бинарные данные документа, который пришел с клиента:

Возврат ошибок — HttpResponseException

Вернуть ответ с ошибкой можно как с помощью HttpResponseMessage, указав код ошибки, так и с помощью специального класса HttpResponseException. Например, на изображении 7 на клиент возвращается ошибка InternalServerError = 500 с коротким описанием. Описание умеют читать далеко не все клиенты или клиентские библиотеки (были проблемы с iPad), в таком случае в тело сообщения с ошибкой можно писать объект более детально описывающий проблему, например свой кастомный объект с сообщением и кодом ошибки.

Хостинг

Само собой разумеется, что Web API REST сервис может хоститься на IIS либо вместе с ASP.NET MVC клиентом либо раздельно. Также его можно легко захостить вместе с ASP.NET MVC Web Role в облаке на Windows Azure. Но интересно, что Web API также можно хостить у себя в приложении, в памяти. Это значительно расширяет круг сценариев, в которых Web API может использоваться. Например с self-hosted Web API можно легко делать интеграционные тесты, которые поднимут во время тестирования self-hosted Web API сервис.

Например, на изображение 8 ниже, показано как поднимается с self-hosted Web API сервис для интеграционного теста в методе BecauseOf.

Клиент

Клиентов к Web API REST может быть большое множество – есть куча библиотек под разные платформы для REST, можно обращаться к REST сервису c веб страницы по средством JavaScript и jQuery, можно использовать “старенький” класс WebClient для десктоп клиента. Вместе с Web API новым для .NET является также новый HttpClient, который очень легко использовать с десктоп клиента или тестового сценария (пример на изображении 8 метод should_make_tivial_get), и к тому же он изначально спроектирован асинхронным.

Илон Маск рекомендует:  Число в CSS
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL
Категория Описание
Алгоритмы шифрования
Вспомогательные классы
Сертификаты X509
Сигнатуры и шифрование XML