RESTFul Api контроллеры в .NET MVC 4

Просто знать, как работает маршрутизация в MVC/WebAPI

Всё строиться на контрактах в вашем приложении, скажем создаётся базовый класс: ResourceBase

  public class ResourceLink
  {
        public string Rel { get; set; }
        public string Href { get; set; }
  }

  public class ResourceBase
  {
        public ResourceLink[] Links { get; set; }
  }

Далее создаём себе столько ресурсов, сколько нам захочеться, к примеру с заказами и оплачеными заказами:

   public class Invoice  : ResourceBase
   {
      public decimal GrandTotal { get; set; }
   }

  public class InvoicePayment : ResourceBase
  {      
  }

Каждому ресурсу присваиваем имя, как вам будет удобнее, можно опять-таки контрактом:

Invoice -> http://foo.com/rel/invoice InvoicePayment -> http://foo.com/rel/invoice-payment

Эти самые relationships должны быть постоянными и не изменяемыми, и более того уникальными.

Дальше всё просто:

POST /invoices/

 <Invoice>
   <GrandTotal>10.00</GrandTotal>
 </Invoice>

И создание оплаты:

POST /payments/

<InvoicePayment>
  <Links>
    <Link rel="http://foo.com/rel/invoice" href="http://bar.com/invoices/12345" />
  </Links>
</InvoicePayment>

Откуда взялся bar.com/invoices/12345?

Просто, для поддержки concurrency в CRUD операциях, сначала нужно получить данные а потом с ними работать, всё как в Entity Framework'e и прочих ORM'ах, что бы гарантировать то, кто изменяемый или удаляемый объект (Entity) существует.

var ctx = new DataContext();
var invoice = ctx.Invoices.Where(x=>x.Id==54123).FirstOrDefault();
ctx.Invoices.Delete(invoice); // не помню, может быть функция как-то по-другому называется.
ctx.SaveChanges();

Точно так же и с ресурсами в REST. Что бы однозначно определить сам ресурс он должен иметь свой ID, а в нашем случаи некий href что гарантированно определяет ресурс.

Таким образом, после создания инвойса, мы получим ответ:

 <Invoice>
   <Links>
      <Link rel="self" href="http://foo.com/invoices/12345" />
   </Links>
   <GrandTotal>10.00</GrandTotal>
 </Invoice>

Где ссылка которая имеет relationship «self» будет содержать ссылку на ресурс, такой себе контракт что бы гарантировать возможность получения уникального идентификатора каждого ресурса.

И для окончательного закрепления, вот работа с оплатой инвойса.

Запрос:
POST /invoices/

 <Invoice>
   <GrandTotal>10.00</GrandTotal>
 </Invoice>

Ответ:

 <Invoice>
   <Links>
      <Link rel="self" href="http://bar.com/invoices/12345" />
   </Links>
   <GrandTotal>10.00</GrandTotal>
 </Invoice>

Имея контракт, что все ресурсы могут содержать коллекцию ссылок, и то, что каждый ресурс гарантированно содержит ссылку с relationship «self» получить идентификатор ресурса не представляется сложной задачей, нашли.

Запрос
POST /payments/

 <InvoicePayment>
  <Links>
    <Link rel="http://foo.com/rel/invoice" href="http://bar.com/invoices/12345" />
  </Links>
</InvoicePayment>

Как self превратился в foo.com/rel/invoice? Мы ведь договаривались что relationships — это well-known данные, так сказать константы которые гарантированно имеют уникальное имя и указывают на вполне определённый ресурс.

B наш ответ:

 <InvoicePayment>
  <Links>
    <Link rel="self" href="http://bar.com/payments/12345" />
    <Link rel="http://foo.com/rel/invoice" href="http://bar.com/invoices/12345" />
  </Links>
  <Created>01/09/12 10:00AM</Created>
</InvoicePayment>

Как мы видим, наш ответ уже имеет ссылку на самого себя и ссылку на другой ресурс, получить который можно найдя ссылку с нужным relationship и сделав GET

Возникает вопрос, а как обрабатывать все эти ссылки на стороне сервера, т.е. в контроллере?
Просто! Через RouteData

public void Post(Payment payment)
{
   var invoiceLink = payment.Links.Single(x=>x.Rel=="http://foo.com/rel/invoice");
   var invoiceData = RouteTable.Routes.GetRouteData(invoiceLink.Href); // в WebApi будет чуть-чуть отличаться
}

Перед тем, как объяснить, что же будет в RouteData нам нужно представить, как же выглядит контроллер для получения одного конкретного инвойса через GET

public class InvoiceController : ApiController
{
    public Invoice Get(int invoiceId)
    {
            // тут реализация
    }
}

Дак вот, в invoiceData будет ключ-значение, где ключом будут имена параметров метода, а значением — значение параметра. Т.е. в нашем случаи там будет ключ «invoiceId» со зрачением 12345

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

Сформируется следующий запрос: вложенным запросом выберется десять элементов, и потом из них пропустится 1000 элементов, т.е. по сути ничего не вернет. Профайлер ЕФ у меня дал такой SQL запрос:

SELECT
[Limit1].[Id] AS [Id],
[Limit1].[Name] AS [Name]
FROM ( SELECT TOP (10) [c].[Id] AS [Id], [c].[Name] AS [Name], row_number() OVER (ORDER BY [c].[Id] ASC) AS [row_number]
        FROM [dbo].[Models] AS [c]
)  AS [Limit1]
WHERE [Limit1].[row_number] > 1000
ORDER BY [Limit1].[Id] ASC