A new option to create OData: Web API

The Microsoft. NET developer was able to create a OData source long before the OData specification appeared. WCF Data Services enables you to expose an Entity Data Model (EDM) on the Web using a representational state transfer (REST). In other words, these services can be used via the following HTTP calls: Get, put, DELETE, and so on. As the framework for creating these services evolves (changing names several times), the output is evolving and eventually forming in the form of a OData specification (odata.org) package. There are a number of client APIs that can be used with OData, such as. NET, PHP, JavaScript, and many other clients. Until recently, however, the only way to easily create a service was through WCF data services.

The WCF data Service is a. NET technology that can be simply encapsulated by an EDM (. edmx, or a model defined by Code first), and then exposes the model for HTTP queries and updates. Because these calls take the form of URIs (such as Http://mysite.com/mydataservice/Clients (34)), you can even execute queries through tools such as Web browsers or Fiddler. To facilitate the creation of WCF data Services, Visual Studio provides a project template that can be used to build data services that use a set of APIs.

Now there's a new way to create a OData source-take advantage of the ASP.net Web API. In this article, I'll outline some of the differences between the two methods and give guidance on how to make choices between them. In addition, I will introduce some of the OData API creation methods that are different from creating Web APIs.

API for Data Services (macro-perspective)

A WCF data service is a System.Data.Services.DataService that wraps a defined ObjectContext or DbContext. When the service class is declared, it is a generic dataservice (that is, dataservice<mydbcontext>) that contains the context. It is completely locked at initial time, so you should set access permissions in the Dbsets constructor that needs to expose the service's context. That's all you need to do. The rest of the work is handled by the underlying DataService APIs: interacting directly with the context in response to the client application HTTP request for the service, and querying and updating the database. Alternatively, you can add some custom settings to the service, overriding some of its query or update logic. In most cases, however, the goal is to have DataService responsible for most of the interaction with the context.

On the other hand, you can use the Web API to define context interactions in response to HTTP requests (put, get, and so on). The method is exposed by the API, and you define the method logic. You do not have to interact with the Entity Framework or even the database. You can have an in-memory object that the client is requesting or sending. Access points are not created as magically as when using WCF data services; instead, you are required to control how to respond to these calls. This is the deciding factor for exposing OData by choosing a service rather than an API. If most of the operations you need to expose are simple Create, Read, Update, Delete (CRUD) without a lot of customization, data Services will be your best choice. If you need to customize a lot of behavior, it is more appropriate to use the Web API.

I agree with Microsoft integration MVP Matt Milner at a recent party: "WCF Data services are suitable for starting with data and models and only want to expose them." It is more appropriate to use the Web API when starting from the API and defining what should be exposed. ”

Laying the groundwork with a standard Web API

I've found that for beginners who lack experience with web APIs, it's a good idea to learn the basics of some Web APIs before you know about new OData support, and then figure out how they relate to creating Web APIs (for public OData). In this article, I'll do this by first creating a simple Web API that uses the Entity Framework as its data tier, and then converting it to provide results in OData form.

One of the purposes of the Web API is as a substitute for a standard controller in a model-view-Controller (MVC) application that can be created as part of the ASP.net MVC 4 project. If you do not need a front-end, you can start with an empty ASP.net Web application and then add a Web API controller. However, to take care of the novice, I will start with the ASP.net MVC 4 template (because it provides a scaffolding that will generate part of the start code). Once you understand how each part is combined, you can start working directly from an empty project.

So I'm going to create a new ASP.net MVC 4 application and then, when prompted, select an empty template (not a Web API template that is designed for a more powerful application that uses views, which is overkill). This generates an MVC application project organizational structure that Models, views, and controllers are all empty folders. Figure 1 compares the results generated by the empty template and the Web API template. You'll find that an empty template generates a much simpler organizational structure, and all I need to do is delete a few folders.

Figure 1 asp.net MVC 4 project generated using an empty template and Web API template