I have recently discovered OData & the new WCF Web APi library on codeplex. The web api allows me to expose results as IQueryable, which allows me to expose URL's in the OData format. Myn question is what is the difference between this and a regular OData Service, I read the following blog post http://phejndorf.wordpress.com/2011/07/15/wcf-web-api-odata-format-doesnt-mean-odata-service/ but I am unsure what the OP means.
Thanks
The WCF Web API supports adding a [QueryComposition] attribute to a function so you can use the OData $filter=.. style of filtering data on the server and sending only a subset back to the client.
With OData, I should say WCF Data Services, there is much more that just querying. You can do all of the CRUD operations. It also means you are using the OData, is an AtomPub superset, protocol where with WCF Web API you do whatever you like. OData is actually a hypermedia format that contains metada, relations etc.
Related
Could someone please help me with the below question??
Difference between MVC Action Methods and Web API Action Methods
The only difference I know, was the return types of both methods.
MVC Action method Return Type:
ActionResult (It is abstract class) and all the derived classes.
Web API action Method return types:
Void
Primitive Type/Complex Type
HttpResponseMessage
IHttpActionResult
Appreciate the further differences between those two. Thank you.
Both MVC and Web API action can return ActionResult or IActionResult type objects. So that is no longer a difference.
Here are few differences if you are still looking for some:
In Web API, a request is mapped to an actions based on the HTTP verbs. Not for MVC
Based on the Accept header in the request Web API returns data in requested format (e.g. XML or JSON)
With Web API you can create RESTful services based on Dotnet Framework. But cannot with MVC
With MVC we can build Web application that can return both data and views but Web API is for sending data only
There are many differences between MVC and Web API, including:
We can use the MVC for developing the Web application that replies as both data and views but the Web API is used for generating the HTTP services that replies only as data.
In the Web API the request performs tracing with the actions depending on the HTTP services but the MVC request performs tracing with the action name.
The Web API returns the data in various formats, such as JSON, XML and other format based on the accept header of the request. But the MVC returns the data in the JSON format by using JSONResult.
The Web API supports content negotiation, self hosting. All these are not supported by the MVC.
The Web API includes the various features of the MVC, such as routing, model binding but these features are different and are defined in the "System.Web.Http" assembly.
And the MVC features are defined in the " System.Web.Mvc" assembly.
The Web API helps the creation of RESTful services over the .Net Framework but the MVC does not support.
I want to use OData as API-Gateway. Is it possible? Is there any example of OData that get rest request and use another service instead of entity framework provider?
I have some service that provide data and my services are using deferent type of databases SQL and NO-SQL. I want to use OData as a service provider of my architecture which my clients only see one endpoint and send OData requests then I can manage which service must response the request.
I searched and found there is some way to create custom provider for OData. Is there a way to use OData as API-Gateway?
The documentation on RelayJS says the RelayJS can use node.js as a GraphQL server, but not ASP.NET web service.
How can I use RelayJS with ASP.NET web api end point?
How can I use RelayJS with ASP.NET web api end point?
TL;DR;
By placing a GraphQL server in-between Relay client-side and ASP.NET web api end point.
The Getting Started page of Relay documentation clearly mentions that 2 additional things are needed to use Relay:
A GraphQL Schema: This is your data model. You need to map your ASP.NET web API to a GraphQL schema.
A GraphQL Server: Your client-side speaks to this server. In your case, this GraphQL server will talk to your ASP.NET web API.
A good example of this is GraphQL schema and server wrapping Star Wars API.
Some conecptual clarifications about your question
Relay is a specification. It's actually called GraphQL Relay Specification. It's not restricted to JavaScript. Check Awesome Relay to find the list of languages for which Relay libraries are already available.
It helps to think of Relay and GraphQL as 2 sides:
server-side consisting of GraphQL server, which speaks the schema. It can receive queries and mutation requests. How you prepare and provide the requested data depend on back-end logic. For example, you may have your own database, which you use directly to fetch / prepare the exposed data. Or you may use an external API to fetch / prepare data.
There are libraries in languages other than JavaScript to help you write GraphQL schema and server. Check Awesome GraphQL.
client-side using Relay library, which talks to a GraphQL server and fetches data as needed.
I have a MVC web application and I make some ajax calls from the client to get back json data. Right now I just use MVC Action methods to return this data. I was wondering if I should be using the ASP.Net Web Api for these.
I understand that if I was building a REST solution I should be using it.
But in this case would it be justified to add the extra complexity? Is there any speed gain? I don't really need the Content Negotiation feature or the OData Support.
According to the post here (and the benchmark it references), Web API is a bit faster. Web api performance?
ASP.net Web api support both JSON and xml. Web Api is for implement rest web service on top of MVC application. It would add extra complexity for the application but you implement web api related method in separate controller.
Rest web services are usually faster than Normal SOAP web services.
In your case if your clients are just a web client no need to implement web services. But If you need to share service for different client (widows applications, windows services, third party applications) implement rest service using web API
What is the difference between making calls to mvc controller methods and WCF WEB API Rest Service Calls?
I can create an mvc controller post method that will allow me to execute any code i need.
I can also create a WCF Web API REST Service with MVC.
What is the difference between these two approaches to accessing data ?
More specifically what are the advantages of utilizing WCF in this scenario ?
WCF Web API handles XML and JSON out of the box whereas you'll have to create your XML and JSON "by hand" (read: using the Serializers) when using MVC - this is only one of the benefits of WCF Web API over MVC.
Another one is the level of separation WCF Web API offers e.g. implementing your service logic vs. content negotiation.
Yet you can easily use IoC containers and unit test your APIs being created using WCF Web API.
WCF Web API mainly has been created to build ReSTful API's whereas MVC just allows it to create them too - thus with WCF Web API you'll feel more comfortable creating ReST APIs.
If you're planning to start a project from scratch as an Web (ReST) Api, you should start with WCF Web API.
If you're planning to start with a Website that also offers ReSTful Services, you should suggest MVC.
You should also regard this tweet from Glenn Block.
You could accomplish a typical REST API with either one.
Usually the issue boils down to (1) what specific features you need and (2) what technology you are more familiar with.
There are some features of WCF that are really neat and not available in MVC (like binary serializations, the ability to host without IIS, et cetera) but those are not typically requirements in a REST API.
Overall I would say:
If you have an WCF implementation already in place and want to expose it as a REST API go for it with WCF.
If you already have an MVC site and want to expose it as a REST API stick with MVC.