REST aplikace pomocí ASP.NET MVC

11.20 - 26. října 2008 | ASP.NET 2.0

Jednou z důležitých novinek v beta verzi ASP.NET MVC je bezesporu možnost přetěžování akcí a ve spolupráci s filtry na typ požadavku můžeme přejít na REST přístup k architektuře webové aplikace.

Ačkoli si mnoho lidí myslí, že když píšou v ASP.NET MVC, mají rovnou REST out of the box, není tomu tak. V plném RESTu se totiž nedostávají do URL slovesa (akce), nýbrž pouze předměty. Typický scénář CRUD operací může vypadat následovně:

POST /Customers/Create/
GET /Customers/Detail/1
POST /Customers/Update/1
GET /Customers/Delete/1

Takovéto akce snadno pokryjeme s výchozí routou /{controller}/{action}/{id} a řadič CustomersController může vypadat nějak tak:

public class CustomersController : Controller {
  public ActionResult Create(Customer customer) {
    // TODO: create customer
  }

  public ActionResult Detail(int id) {
    // TODO: find customer by id
  }

  public ActionResult Update(int id, Customer customer) {
    // TODO: update customer
  }

  public ActionResult Delete(int id) {
    // TODO: delete customer
  }
}

Jenže POSTování a GETování je jen slabou podmnožinou povolených operací na HTTP protokolu. Správný REST přístup pro CRUD operace by měl vypadat následovně:

POST /Customers
GET /Customers/1
PUT /Customers/1
DELETE /Customers/1

Co je pro to třeba udělat?

Začneme od routy. Přidáme novou routu pro CustomersController:

routes.MapRoute(
  "REST Customers",
  "Customers/{id}",
  new { controller = "Customers", action = "Rest", id = "" }
);

A původní kód obohatíme o pár atributů:

public class CustomersController : Controller {

  [ActionName("Rest")]
  [AcceptVerbs(HttpVerbs.Post)]
  public ActionResult Create(Customer customer) {
    // TODO: save Customer to database
    return Json(new { status = "ok" });
  }

  [ActionName("Rest")]
  [AcceptVerbs(HttpVerbs.Get)]
  public ActionResult Detail(int id) {
    // TODO: load Customer from database
    return View("Detail");
  }

  [ActionName("Rest")]
  [AcceptVerbs(HttpVerbs.Get)]
  public ActionResult Index() {
    // TODO: load Customers from database
    return View("Index");
  }

  [ActionName("Rest")]
  [AcceptVerbs(HttpVerbs.Put)]
  public ActionResult Update(int id, Customer customer) {
    // TODO: update Customer in database
    return Json(new { status = "ok" });
  }

  [ActionName("Rest")]
  [AcceptVerbs(HttpVerbs.Delete)]
  public ActionResult Delete(int id) {
    // TODO: delete Customer from database
    return Json(new { status = "ok" });
  }
}

A máme REST :)

Komentáře

Vybírání metody, která se nakonec použije, pomocí atributů je výborná věc. Implementovat lze i vlastní rozhodovací logiku, což je konkrétně pro MVC webové služby často užitečné.

To vytvoření kontroleru je jen polovina, jak pak zavolám akci pro smazání nebo update?

[2] Petr: Tuším, že nějak tak:
POST /Customers
GET /Customers/1
PUT /Customers/1
DELETE /Customers/1
lze toho docílit záhadným atributem method elementu form nebo AJAXovým voláním. Klasický odkaz bude fungovat jen na detail, což je IMHO správně…

Ale to jsou přece základy. Doučit!

No jo, jenze v atributu method je povoleno jen POST nebo GET – cokoliv jineho se tusim posila jako GET.

[4] Danielle: ok, ale dá se snadno na form pověsit JS ovladač události, který to pošle správnou metodou. viz např. http://www.onjava.com/…restweb.html

SOučástí HTML5 však už jsou tyto 4 metody podporovány, tudíž, by měla být podpora v prohlížečích buďto přítomna, nebo brzo doplněna. viz http://www.w3.org/html/wg/html5/#…

Ahoj, pochopil jsem jak to myslíš, ale přesto si nemůžu odpustit jeden dotaz, který se týká těchto dvou položek.
POST /Customers (nový záznam)
PUT /Customers/1 (update záznamu)
Kde se dostanu na formuláře pro vložení a editaci záznamu? „GET /Customers“ pro vložení záznamu nepřipadá v úvahu, protože tam předpokládám má být seznam záznamů. „GET /Customers/1“ pro update taky ne, protože tam už mám detail záznamu.

Ano, díky přetěžování akcí to lze udělat tak, že „POST /Customers“ může zobrazit formulář a následně vytvořit nový záznam v DB. Ovšem za spolupráce JavaScriptu. Možná to z mé strany není zrovna in, ale není to trochu škoda?

[6] Dušan Janošík: Toto schema je dobré pro CRUD operace – tedy API pro práci s daty – a s UI nemá nic společného.

Pokud chceš formulář zavolej např. GET \Customers\New, nebo vytvoř partial view s formulářem, ktere se načte třeba AJAXem nebo bude součástí UI vypisu uživatelů.

Titmto způsobem pracujou i RoR, pro více informací doporučuje omrknout to tam :)

[7] Aleš Roubíček: Ok, díky za objasnění.

[3] Aleš Roubíček: Jak už tě poučila Danielle, tak do formuláře lze zadat jen post a get :-).

Změna pomocí JS dle mého nepřipadá v úvahu, je moc často blokován adblokem.

Po nahlédnutí do odkazovaného článku si odpovím sám, prostě hidden parametrem. Pak ale ale otázka jestli je hidden parametr lepší, než adresa /Customers/Delete/1…

[9] Petr: Samozřejmě v ničem, ale není to pak REST, o kterém je tento článek.

Hnidopisska poznamka, routovani je hierarchicky prirozenejsi takhle /customers/{id}/akce :)

[11] ja: Přirozenější je názvy akcí v routě vůbec nemít. O tom byl tento článek. Každopádně routa {controller}/{action}/{*params} je konvence frameworku, ne můj výmysl. Obhajitelné jsou oba postupy.

Místo pro tvůj názor

O autorovi

Jmenuji se Aleš Roubíček a jsem vývojář webových aplikací na platformě ASP.NET. Pracoval jsem v portálu Atlas.cz na katalogových aplikacích. Nyní pracuji v Twaregu na web 2.0 projektech a na reklamním systému. Zajímám se o webové technologie všeho druhu v poslední době především o mikroformáty, ASP.NET MVC a Silverlight. Pokud na mne máte nějaký dotaz nebo tak, neváhejte mne kontaktovat.