WebAPI: версионирование на основе HTTP-заголовков

Допустим, что для различных версий API существуют разные контроллеры
Если необходимо делать выбор контроллера на основании заголовка, то для этого предлагается определить свою имплементацию интерфейса IHttpControllerSelector в ServicesContainer

Какой именно HTTP-заголовок необходимо использовать особо не важно, будь то Accept, или свой, например - X-Version (я выбираю Accept, исключительно из любопытства)

Легче всего реализовать IHttpControllerSelector - создать наследника DefaultHttpControllerSelector:

Swagger: внедрение произвольных http-заголовков

Если при необходимости использования web api через swagger необходимо отправлять кастомные http-заголовки, то это можно сделать очень просто
  1. открываем SwaggerConfig
  2. ищем метод, переданный в EnableSwaggerUi
  3. вызываем InjectJavaScript у объекта, типа SwaggerUiConfig (передаётся в качестве первого аргумента обработчика)
  4. В качестве параметров необходимо передать :
    1. сборку, содержащую js в качестве рекурса
    2. название ресурса

Swagger: переадресация help page на swagger

Немного ранее было описано, как установить и использовать Swagger для использования в качестве автодокументации к Web API

Многие привыкли к адресу документации по адресу help/, но swagger отдаёт доку, конечно же, по своему адресу swagger/ui/index

Первое что приходит в голову - сделать свой собственный RedirectHandler, но в сборке Swashbuckle.Core уже таковой имелся :)

Собственно редиректим старую урлу на новую путём добавления следующего кода в метод Register класса SwaggerConfig


Теперь по обращении к help/ будет редирект на swagger/ui/index

Web API: автодокументация (Help Page / Swagger)

Иногда очень удобно вместе с API иметь страницу показывающую реализованные в данный момент интерфейсы/методы и модели

При создании Web API проекта из VS 2015 в настоящий момент предлагается ASP.NET Web API Help Page, и работает решение практически из коробки
Необходимо лишь решить - нужны ли комментарии к методам и свойствам моделей

Но в ASP .NET Web API Help Page есть существенные недостатки:
  • методы можно посмотреть, но нельзя вызвать тут же
  • для генерации моделей для PATCH требовались дополнительные телодвижения, например через метод SetSampleForType, а хочется всё же - большей гибкости (создал метод/модель - пользователи тут же могут её увидеть)
  • Когда бизнес-логика и модели отделены от Web API (собственно контракты/модели в одной библиотеке, а модели в другой, web api - в третьей) help pages не даёт возможности указать несколько XML-документов. Как следствие - необходимо их смёржить, а после - указывать базовый
  • Слишком много телодвижений (переходов меж страницами)
  • Нельзя указать список возвращаемых HTTP-кодов
т.е. получается вроде бы как результат есть, но что-то не то

Swagger же лишён всех этих недостатков
Проявил себя в самом лучшем виде и уже несколько месяцев после начальной настройки под себя - мы его боле не трогали (проект немного специфичный, необходимо иметь возможность отправлять кастомные http-заголовки).

Потому я и выбрал Swagger, успешно подсадив на него всю команду и, как результат - множество вопросов отпадает, тестировать методы можно до реализации клиента (человеческие тесты), да и просто приятно пользоваться.

Тем не менее сначала рассмотрим краткую инструкцию о том, как создать ASP .NET API Help Page, а после - перейти на Swagger

ASP.NET Web API: Отмена долгих запросов

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

Чем это чревато: если запросов будет довольно много, то отправив много запросов можно заблокировать все потоки в пуле, тем самым сделав недоступным сервер для обработки новых запросов.

Как вариант - заюзать на фронте nginx

А если допустимо - принимать CancellationToken и передавать его в долговыполняющиеся операции

Это может понадобиться в случае, если пользователь может сам отменить запрос или ему надоело ждать и он закрыл браузер

ASP.NET MVC 6 Dependency Injection (внедрение зависимости)

Ниже будет слегка рассмотрена реализация dependency injection от ms в рамках базового шаблона ASP.NET MVC 6
Использованные классы написаны только для демонстрации и некоторые вещи не стоит делать в проде
Также для всего этого дела использованы некоторые фичи C# 6, just for fun
Извлечение реализации определённого интерфейса будет представлено в четырёх видах (хотя все они сводятся к одному, но при использовании сильно отличаются)

Итак, подробный разбор ниже

JavaScript без jQuery - несколько примеров

Не нужно использовать jQuery там, где вся его мощь ни к чему, т.к. многие вещи вполне спокойно делаются и без него

Ниже вы увидите примеры для следующих ситуаций:
  • Подписывание на окончание загрузки документа
  • Выборка элементов используя css-селекторы
  • Добавление/удаление подписчиков на события
  • Манипуляция с классами элемента
  • Работа с аттрибутами элементов
  • Управление контентом
  • Добавление/удаление элементов
  • Проход по DOM
  • Использование анимации
  • AJAX

remote: fatal: bad config value for 'pack.deltacachesize'

Заходите в серверный .gitconfig и прописываете примерно cледующее:

[core]
    packedGitLimit = 256m
    packedGitWindowSize = 32m

[pack]
    deltaCacheSize = 256m
    windowMemory = 256m

ASP.NET WebSocket

Ниже пример реализации WebSocket-сервера на ASP.NET via C#:
  1. Создаём новый пустой веб-сайт, в качестве фреймворка я выбрал 4.5.2
  2. Добавляем в корень файл CustomWS.ashx:

  3. Добавляем файл form.html

  4. И последний index.html
Короткое объяснение:
  1. Для обращения к веб-сокетам из JS необходимо использовать класс WebSocket, см. подробнее например здесь: https://learn.javascript.ru/websockets
  2. На серверной стороне сделан хендлер для обработки запроса, благодаря свойству context.IsWebSocketRequest можно понять, это запрос но открытие веб-сокета или нет
  3. Если запрос содержит начальное подтверждение AspNetWebSocket, то регистрируем обработчик через context.AcceptWebSocketRequest
  4. Ну а дальше см. код

Пример работы:

Ссылка на проект:

  1. web http://sansys-net-websockets.azurewebsites.net/
  2. исходники https://cloud.mail.ru/public/dacVwJuHUh8y/DemoWebSockets.zip
PS: 
  • текущий проект в ажуре допускает максимум 5 одновременных подключений, так что вы можете легко увидеть ошибки, лучше качайте исходники и смотрите локально, + можно попробовать всё ручками
  • код не является потокобезопасным для простоты