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 thats 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 thats 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 thats in the request and say, if theres 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 its 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 theres 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 tambin se logra lo mismo (localhost.fiddler)