It leverages model binding for taking incoming parameters from the URL or from the HTTP body and

passing those as strongly typed parameters to your controllers methods. And it can also leverage action

filters, the most common of which is the authorized filter that’s used for security and authorization, but

you can also write custom ones that plug in. They basically provide pre and post processing before your

controller methods are invoked.

Convention over configuration: One of the keys concepts of ASP.NET Web API is a thing called

convention over configuration. And the idea here is that other technologies like WCF require a lot of

explicit configuration in you application config files. So with WCF, you would have to configure services

and endpoints and binding and addresses and contracts and behaviours and binding modifications and

you end up with a whole lot of explicits configuration in a config file. Convention over configuration says,

you know what, if we go with some basic naming conventions we can infer a lot of that stuff and we can

infer exactly what we need from the code definitions themselves instead of having explicitly configure it.

So if you take a request that is coming in, like the one shown on the slide here, this represents a raw

http request and its got the information that goes into the request itself in the form of headers. Below

it, you see a controller class and the basic structure of a controller class inheriting from API controller. So

some of the things we can use convention over configuration for,

Is first if you can see a portion of the URL that’s in the request identifies customers. Well we can infer

from that that this request is destined for the Customer controller. So the naming convention there is it

ignores the trailing controller suffix to the class name, and it matches up customers to customers

controllers

Next it can look at the HTTP verb that’s in the request and say, if there’s a method that starts with get

that probably corresponds to the GET HTTP verb. And so it can route to the specific method based on

the verb

Next it can take parameters encoded in the URL as either a URI or query strings parameters and map

those automatically to the parameters of the target method. So the ID parameter here is based on the

routing, and we will see that in the demo, and the include orders parameters here is a query string

parameters and it can match that up by name explicitly as long as the name is exactly the same as a

parameter name, it assumes that that is where that piece of data is supposed to go

Content Negotiation: Another big part of Web API is content negotiation,content negotiation says that

you should not to prewire or configure exactly what formats you are going to support at a wire level for

the data going back and forth. So you can base it off of some standardized headers in the HTTP protocol

called the Accept headers and the Content-Type header. So what this look like is if we have a request

like this coming in a get request to this address and you can see it’s going to the customer controller and

its got and extra URI parameters of ALFKI there for our customer ID, but down at the bottom you can

see there’s an accept header that says what we want back, the representation we want back for that

customer is formatted as application/json

To define a simple CRUD oriented data service with a web API, you first have to follow some of the

fundamentals that I've covered earlier in this module, and we'll see that in a demo shortly. Next, you

need to think about what you're going to expose and how it aligns with controllers and services. So,

specifically in the vein of thinking about resources and not operations, your data collections themselves

will be the resources you expose and you can think of one entire database as a resource, but you need

to be more fine grained than that. So typically you're talking about table level collections are individual

resources. Then you're going to map that data collection into being a single controller. So for example,

using a Northwind type schema, you would have a Customers controller, an Orders controller, and

Employees controller, and so on. Then you've got to map the HTTP verbs that are going to come in into

the CRUD Actions and map those CRUD Actions onto controller methods. So what it's going to look like

is this. First off, the POST verb corresponds to creating a new resource. So, you would map that on to

the create action of CRUD, which corresponds to an insert at a database level and you could name a

method on your controller. For example, POST customer and then your controller might be named

Customers controller. Now you're not required to have that customer suffix to your method name. All

that really matters on your method names in terms of the routing scheme is the prefix there of the verb

that maps to it. You can put whatever you like after the verb and the routing system will ignore that, but

I find it helpful to go ahead and put that because you can see here that you can map to the plurality that

a POST, PUT, and DELETE, for example, work against a single customer, whereas a GET can act against all

customers or a single customer. So a POST corresponds to a create or insert type operation. A GET

corresponds to retrieving, but again, retrieving could be GET all customers or some set of customers,

and it also can be retrieving a single customer's full details. So you'll typically have those two variants

there, one of which takes some sort of identifier to get a single instance of a resource out of the

collection. The PUT verb, as I've mentioned before, corresponds to a modification or an update

operation. And then DELETE obviously corresponds to delete.

ODATA

Okay, so finally to wrap up this module, I wanted to talk about OData at a high level to give you the key

concepts so that we can dive into how to implement OData in the rest of the course with web API. OData

is an open standard protocol. It was initiated and is led by Microsoft, but it is supported by a number of

different platform vendors as you'll see when I get into tools and libraries and things in the next module.

You can find the full specification and other details about the protocol at OData.org is the main landing

site for the spec. The general idea is that you're going to expose data over HTTP services for querying and

possibly updating. I would say OData is more about the query side than the update side, but certainly if

you expose that data, you want to be able to update it and you don't necessarily want to have to go to a

custom protocol to do so. OData embraces the REST architectural style, so it is full blown REST with all the

aspects I talked about earlier in this module about leveraging the URI for an addressing scheme, using

HTTP verbs to indicate what type of action you're trying to do, using specific headers and response status

codes and content negotiation, and they also go the final mile, the part that I said most people who say

they're doing REST aren't actually doing it according to the original definition by Roy Fielding there

because they're not doing hypermedia linking whereas OData actually does include hypermedia linking.

So you'll get links imbedded in the representations of resources that come back to you and those links will

include links to related resources, so things like if you get back a customer and it's got orders, those can

come back as links instead of imbedded representations. And you will also see hypermedia links imbedded

for the allowable actions on a given resource. So you'll have action links for example, for doing updates

or deletes and things like that, and it will show you what the URL is that you go to do that. Additionally,

something OData does even though it's a REST-based service, one thing you give up with REST in general,

is that if you've ever been exposed to WCF, WCF includes metadata with its services and that means that

you can code generate client proxies to call those services very easily. When you go to a REST-based

service, you lose that. REST in general has no protocol for metadata, but the OData spec does include a

metadata specification for its services. And that means for an OData endpoint, you can expose that

metadata and have some client side code generation for consuming the endpoint and we'll see that when

we get into the WCF data services client in the next module. Current version of the OData spec is 3.0. It's

gone through three generations of evolution and enhancements so it's pretty mature specification at this

point. Basically, OData is broken down into two major parts. The first part is the OData Query Syntax, and

this is basically the way that you encode into the URL the query that you want to execute on the server

side. So it includes not only the data service address itself and what the entity set or resources that you're

going after, but it can include navigation properties to related resources and more importantly it can

include operators and functions for doing things like filtering, ordering, paging, and so on. The second part

of OData is formatting and there's two formats you can choose from. One is an XML based format that is

the ATOM Publishing Protocol. Now you might recognize that acronym if you're a blogger. That's one of

the common formats that people publish their blog in along with RSS. But the ATOM Publishing Protocol

also includes definitions for how you express updates, deletes, and adding items so you're able to cover

the update side of things as well. There's also a JSON formatting and there's really two variations of that.

There's the original JSON formatting that came out with the OData 1.0 spec. That's currently being

referred to JSON Verbose and there's a new, lighter weight format that leaves out some of the additional

hypermedia linking and some of the metadata that goes into that payload to keep the JSON very

lightweight, especially for mobile devices where bandwidth consumption matters. So the OData spec

includes support to pick between JSON Verbose or JSON Light and the web API supports that as well. The

media types you'll see in your Content-Type headers or your Accept headers in the HTTP spec is the

application/atom+xml for ATOM Publishing Protocol or just application/json for the JSON formatting.

OData does leverage the full HTTP verbs of GET, PUT, POST, and DELETE and it supports two others, PATCH

and MERGE, which are used for update scenarios where you don't want to have to send all of the

properties of a given object when only maybe one or a few have changed. So it allows you to do delta

type operations where you only send the modified properties of a given object and apply those on the

back end. So that's kind of the whole of OData at a very high level and then the remaining modules of this

course will dive into how to expose services with it, how to support the query syntax, and how to support

the formatting as well.

Summary

So in summary to wrap up this module, you saw that ASP.NET Web API is a great new platform for building

HTTP services, very easy to use, and allows you to scale from simple remote procedure call style services,

CRUD services, REST architectural style services or OData services. Web API emphasizes convention

over configuration to make it very quick and easy to define your controllers as services and not have to set

up a bunch of configuration to get them exposed. The web API has a number of extensibility points with

message handlers, filters, and formatters that allow you to customize its behavior in processing

messages. The REST architectural style is something that lets you fully leverage the HTTP protocol and it

emphasizes resources and representations instead of remote procedure call operations. To define a CRUD

service, you saw with the slides in the demo there that basically you just expose methods and correspond

to the GET, PUT, POST, and DELETE verbs of the HTTP protocol and generally you'll set these up as a data

collection-centric resource controller. And finally, you got a quick intro to the OData protocol and what's

involved, the fact that it involves both query syntax and formatting, and it's a standardized way to expose

CRUD oriented services that are fully RESTful themselves.

In this module, I'm going to talk about the OData Platform, tools, and resources. So I basically want to give

you a sense of the broader ecosystem of OData as a whole so that you can see some of the benefits of using

it in the multiplatform aspect of it. First, I'm going to go into OData support across multiple server platforms,

so focusing on the server side and talking about the many different ways you can expose OData, and a lot

of these you'll see are things you'reprobably already using in your systems and in your applications and you

may not even realize that they support OData themselves. Next, I'm going to compare and contrast WCF

Data Services and Web API OData. At a high level, they both seem to do the same thing, so the question

often arises when should I use one or the other. Next, I'll talk about WCF Data Services and give you a sense

of what does it look like to implement OData Services with that platform and I'll do a quick demo there so

that you have that to compare and contrast yourself as we dive into the details of doing it with Web API in

the rest of the course. And I'll finish this module by talking about some of the OData tools and libraries that

are out there for implementing client applications and for consuming OData, both for debugging and

diagnostic purposes and just for general querying and consumption of the data.

OData Support Across Platforms

When it comes to exposing OData, you have a number of options available to you. WCF Data Services was

the first support for exposing OData. As I mentioned, Microsoft really initiated the protocol and WCF Data

Services was first released as the way you would go about building an OData service on the Microsoft

platform. But other products and platforms very quickly joined in to support the protocol as well. So,

Node.js, PHP, and Java all support exposing OData services in their own different ways. SQL Server

Reporting Services allows you to expose the data directly from the database as an OData feed. So you can

go and query the contents of your reporting services using OData. SharePoint exposes its lists and

documents in a way that can be consumed using the OData specification. Windows Azure Table Storage,

which is basically flat tables, not fully relational, but it's able to support OData for querying those tables

and doing filters and orders and paging and so on. Windows Azure Data Marketplace is a platform offering

on the Windows Azure platform. You may have heard of this referred to as Microsoft Dallas. It's really just

a cloud-based version of deploying data services into the cloud for broad public consumption. So you'll

find things out there in the data marketplace where you can basically pay to access data, things such as

public census polls, medical statistics, government tax rates, and all kinds of things like that that you might

need to incorporate as source data into an application that you can just go and pay for data as a service,

and those are all exposed using OData. IBM has gotten fully behind the OData protocol as a platform

vendor. Their WebSphere product allows you to expose OData services. DB2, similar to what I had talked

about with SQL server, you can expose data services directly from DB2 itself, and their Informix product

also supports exposing OData feeds. And finally, what we'll be focusing on in this course obviously is

ASP.NET Web API's way of exposing OData.

WCF Data Services vs ASP.NET Web API OData

Now I want to talk a little bit about the similarities and differences between WCF Data Services and Web

API OData, because there is a fair amount of overlap between the two. First off, as far as WCF Data Services

is concerned, you don't actually have to know anything about WCF even though it's in the name. Coding

WCF Data Services looks nothing like coding normal WCF Services. You don't define service contracts and

implement those service contracts and put a bunch of configuration in place like you would with a normal

WCF Data Service. You just drive from a data service class and you're off and running very quickly, as you'll

see in this module. WCF Data Services is really the most complete implementation of the OData

specification that's available at the current time for Microsoft. So web API OData is a little bit more new,

and as we'll talk about, it's missing a few of the features that WCF Data Services has at the current time,

but it has some distinct advantages as well over WCF Data Services. Where WCF Data Services really shines

is when you have an existing data store that you want to expose as a service with very little intervening

logic. So you really want to just expose a pipeline to the web or to a network for people to come in and

query your data store and possibly perform updates against it. If you do need to have some logic that sits

between the caller and the database, the coding patterns are a little awkward or are just not quite what

you'd be used to. You don't really sit and write code that sits as a layer between the caller and the

database. It's more that you get to peer into a pipeline where the data is flowing by and you have a chance

to intercept that and influence it, but coding up complex business logic between the caller and the data

access can be difficult with WCF Data Services. The other thing where WCF Data Services can get fairly

complex is if you need to go out to a non-LINQ provider or a non-IQueryable source, then it can get very

difficult with WCF Data Services. And if you need to do anything that goes beyond the realm of what WCF

Data Services was really designed to do to this pipeline of data to the caller, it's not very extensible for

plugging in custom patterns. It's more of a black box. It works very well for what it was designed for, but

you can't really tack custom stuff onto the side of it very well. Web API OData, on the other hand, is a new

addition to the web API stack as we've talked about. It's available through a NuGet package and will

eventually be rolled in with the next major release of Web API. At the current time, it doesn't support all

of the OData operations yet and we'll talk about what some of the specific ones missing are in the next

module. But one good thing is the ASP.NET Team is very agile and they do get short release cycles of

getting new updates out through the NuGet packages and putting the work in progress out on the web

through the Aspnetwebstack.codeplex.com. So that means you won't have to wait for a full release of the

.NET framework to see enhancements to the Web API OData, it'll probably come more incrementally

through these interim releases. One of the big advantages of ASP.NET Web API is you're much more in

control of what's going on in the code that answers the incoming OData calls. So you have more direct

control of the underlying data sources, the model definition, and the routing conventions that get the

calls dispatched into your controller methods. As a result, the Web API is also an easier programming

model if you want to have intervening business logic. If you want a more layered architecture where the

caller calls our service, your service calls the business layer, that business layer calls the data layer, it's

much easier to have that layered architecture with the Web API than it is with WCF Data Services. Web

API OData also lets you have more of a hybrid site so you can have multiple models, exposed via OData

from a single site, and you can mix in other web APIs and non-OData services sitting side-by-side with your

OData services. And finally, the way the ASP.NET Web API functionality is put together, it's a much more

extensible model. So if you have very domain specific things you want to do that the Web API doesn't

already support, you have a much better chance of being able to support those on your own instead of

having to wait for the framework to be updated to support those in a more general purpose way.

Introduction to WCF Data Services OJOOO quede aqui..

Para usar fiddler para capturar el trafico del servidor web interno de visual studio debo colocar un punto

al final de localhost.

De esta forma también se logra lo mismo (localhost.fiddler)