Статьи

ASP.NET MVC 4 — веб-API

Только что была выпущена бета-версия для ASP.NET 4. Среди многих новых функций, включенных в этот выпуск, — инфраструктура Web API, но что это? По сути, это позволяет вам создавать сервисы, которые могут быть представлены через HTTP, а не через формальные сервисы, такие как WCF или SOAP. Если вы когда-либо использовали API Facebook или Twiiter, вы уже знакомы с ними. Для меня это одна из самых захватывающих новых функций!

Первоначально Web API был проектом веб-API WCF . Разработка API таким способом означала, что вы следовали правилам WCF; начиная с интерфейса, создавая классы, производные от интерфейса, а затем декорируя интерфейс атрибутами WCF для формирования конечных точек. Это был не беглый процесс. WCF сложен, и людям нравится легкость, которую допускает ASP.NET, Microsoft увидела это и создала Web API. Они взяли лучшее из веб-API WCF и простоту разработки, которую позволяет ASP.NET MVC.

Установка

Прямо сейчас вы можете установить бета-версию MVC 4 для Visual Studio 2010 через установщик We Platform. Для этого требуется ASP.NET 4, если вы еще не установили его, и его можно скачать здесь .

Visual Studio 2011 Developer Preview также только что был выпущен для общественности. Как ASPInsider , у нас был доступ к релизу в течение достаточно долгого времени, и я очень доволен новым обликом метро. Если вы хотите установить его, его можно скачать здесь . Весь код и снимки экрана взяты из новой версии.

Начиная

Чтобы начать писать свой первый веб-API, откройте Studio 2011 и выберите веб-приложение ASP.NET MVC 4. Откроется диалоговое окно шаблона проекта. Есть несколько новых вариантов, таких как мобильное приложение и одностраничное приложение (SPA) , но пока выберите Web API.

Перед просмотром любого кода откройте файл global.asax и посмотрите маршрут по умолчанию.

public static void RegisterApis(HttpConfiguration config) { 
 config.Routes.MapHttpRoute( 
  "Default", // Route name 
  "{controller}/{id}", // URL with parameters 
  new { id = RouteParameter.Optional } // Parameter defaults 
 ); 
} 

protected void Application_Start() { 
 RegisterApis(GlobalConfiguration.Configuration); 
} 

Основное различие между маршрутами MVC и маршрутами веб-API заключается в том, что для действия не определен маршрут. Это связано с тем, что Web API использует метод HTTP, а не путь URI, для выбора действия.

Я создал простой класс Product для представления модели и добавил его в папку Models .

 public class Product { 
 public int ID { get; set; } 
 public double Price { get; set; } 
 public string Name { get; set; } 
}

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

Контроллер выглядит так же, но контроллеры Web API наследуются от ApiController.

 public class ProductController : ApiController { 
 // GET: /Product/ 
 public ActionResult Index() { 
  return View(); 
 } 
}

Помните, что веб-API использует методы HTTP, поэтому мы можем отобразить следующие методы HTTP:

действие HTTP метод Относительный URI
Получить список всех продуктов ПОЛУЧИТЬ /товары
Получить продукт по идентификатору ПОЛУЧИТЬ / Продукция / идентификатор
Создать новый продукт ПОЧТА /товары
Обновить продукт ПОЛОЖИЛ / Продукция / идентификатор
Удалить товар УДАЛЯТЬ / Продукция / идентификатор

Соглашения об именах в Web API следуют именам методов HTTP, GET / POST / PUT / DELETE. Вы увидите, как они отображаются в коде в следующих разделах.

ПОЛУЧИТЬ действия

 public List<Product> Get() {  
 return _productsRepository.ToList();  
}  

public Product Get(int id) {  
 return _productsRepository.First(p => p.ID == id);  
}

Обратите внимание, как я определил два действия Get? Это потому, что когда пользователь вызывает API, он передает метод HTTP. Если входящий запрос является запросом GET и не имеет идентификатора, он вызовет действие Get, чтобы вернуть список продуктов. Если идентификатор есть, он вызывает действие Get для определенного продукта. Красиво и просто. И как вы можете проверить этот код? Я собираюсь использовать Fiddler для этого. Если вы никогда не использовали это, вы должны получить это сейчас.

Используя Fiddler, я могу создать запрос GET в компоновщике Composer. Вызов http: // localhost: 1717 / Product вернет список товаров.

Если я хочу только один продукт, я могу передать в ID; HTTP: // локальный: 1717 / Product / 1. По умолчанию JSON возвращается из всех методов действия. Если вам нужен другой формат, например XML, просто добавьте в заголовок приложения Accept application / xml:


Не изменяя код, он возвращает результат в XML.

POST Actions

 public void Post(Product product) {  
 _productsRepository.Add(product) 
}

Следующие запросы GET являются запросами POST. Это где данные будут созданы. Опять же, я назвал действие так же, как глагол HTTP, поэтому все, что мне нужно изменить, — это добавить Content-Type в application / json и отправить объект JSON. Я могу добавить следующие заголовки запроса в Fiddler, чтобы опубликовать новый продукт.

Если вы проверите код ответа HTTP, вы увидите, что он возвращает 200, что нормально, но для POST в идеале он должен возвращать код состояния 201. Это будет указывать пользователю, что продукт был успешным. Также 201 должен иметь значение Location, поэтому мы добавим и это.

 public HttpResponseMessage<Product> Post(Product product) {     
 _productsRepository.Add(product);     
 var response = new HttpResponseMessage<Product>(product, HttpStatusCode.Created);     
 string uri = Url.Route("http://localhost:1717/", new { id = contact.Id });     
 response.Headers.Location = new Uri(Request.RequestUri, uri);     
 return response; 
}

Вместо возврата void мы возвращаем новый тип HttpResponseMessage <T>. Это дает вам гибкость в изменении возвращенного кода состояния, а также заголовков ответов. Теперь, если вы запустите это через Fiddler, вы увидите возвращенный 201 плюс заголовок Location .

PUT Actions

 public void Put(Product product) { 
 _productsRepository.Update(product) 
}

Положите действия по обновлению ресурсов, так что возвращение 200 или 204 вполне подойдет. По умолчанию возвращается 200, поэтому по этой причине нам не нужно ничего делать с действием.

Стоит отметить, что для поста и положенных действий я отправляю JSON. Если я изменю тип контента на XML, я мог бы легко отправлять XML вместо JSON без необходимости изменения какого-либо кода в API. Web API автоматически разбивает входящий запрос на строго типизированные объекты и сопоставляет свойства имени.

УДАЛИТЬ Действия

 public void Delete(Product product) { 
 _productsRepository.Delete(product) 
}

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

 public HttpResponseMessage<Product> Delete(Product product) { 
 _productsRepository.Delete(product); 
 var response = new HttpResponseMessage<Product>(product, HttpStatusCode.Deleted); 
 return response; 
}

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