I am wanting to build a Restful API using WCF however I am struggling to make a decision on how to accomplish this.
The WCF Rest Starter Kit was developed for .Net 3.5 and has not progressed past Preview 2. Although it can be used within the current .NET Framework and within Visual Studio 2010 it seems from my research to be dead in the water and superseded by the new WCF Web API which is currently in Preview 5.
On the other hand the WCF Web API is only at preview stage and should not really be used in a production application as many things could possibly change before its release. There is also no indication if its nearing completion and if it’s going to be in the next .NET Framework release and when that is intended to be.
I find myself between rock and a hard place and look to the wider community to provide me with some guidance on this if at all possible.
You should regard this tweet from Glenn Block.
Using ASP.NET MVC for building a Restful API should be straight forward and easy way to do it.
However I've used WCF Web Api with WCF Rest Contrib in production without any problems.
See
Creating REST API with ASP.NET MVC that can speak both JSON and Plain Xml
RESTful Services With ASP.NET MVC
ASP.NET MVC – Create easy REST API with JSON and XML
Maybe OpenRasta is what you are looking for?
See also
RESTful framework alternatives to WCF
I depends on your application. If its a Website (also has views) that offers the REST API using ASP.NET MVC would be less technology, less effort, less know-how etc.
If its JUST an REST API choose what you like more from development style: ASP.NET MVC or WCF Web API
Related
i need few reason for which people mixed ASP.Net MVC and web-api in same project. when we can develop a full project in mvc only then why web api need to include. also we can host webapi project separately which can server request to MVC and other devs or mobile devs etc.discuss the reason and advantages.
some one answer :
We have recently built a project within MVC and WebApi, we used the WebApi purely because from a Mobile Apps perspective. We allowed the mobile dev guys to call our methods within our MVC application instead of them having to go and create the same function.
WebApi allows to create services that can be exposed over HTTP rather than through a formal service such as WCF or SOAP. Another difference is in the way how WebApi uses Http protocol and makes it truly First class Http citizen.
still the above answer is not clear to me and i think this is not the reason for which people mixed ASP.Net MVC and web-api in same project.
so anyone mind to discuss the actual reason and advantages with example scenario.
thanks
Each have a purpose. Most of the time it's usually caused by legacy code. I know we included documentation which used MVC, but we're fully webapi.
FYI, was MS's auto documentation for WebApi ironically.
Advantage of using WebAPI as ProjectType over InterNet Application in asp.Net MVC?
Is any other use of WebAPI and why it's introduce in MVC4?
To name a few :
ASP.NET web api can be selfhosted outside IIS
ASP.NET web api is not specifically geared towards browsers...
ASP.NET Web api makes making a (level 2/3) RESTful webservice easier
I think that the biggest advantage WebAPI has over other solutions is the built in support for different formats such as XML , JSON, and the relative ease when adding your custom formats. Another advantage worth mentioning is the ability to support extensive OData without coding as much (can be as simple as returning IQueryable), and the support of objects.
That said, WebAPI still have scores of issues that need to be resolved, I keep getting questions from developers that find WebAPI can't resolve their methods, parameters that always result with NULL etc... so I wouldn't swear by it yet, we are all hoping to see a better version sooner rather than later.
I am new to ASP.NET Web API. Can anyone please tell me
Why we need Web API?
How it differs from rest full api from MVC ?
When to use MVC4 web api ?
What is restful api in MVC
WebAPI is based on MVC, but has some subtle differences. You need to understand that WebAPI is a separate thing from MVC, and does not require MVC. You can install WebAPI separately, and you can uninstall it from the default MVC templates.
It's true, MS could have built WebAPI directly into the MVC Controllers, but they chose to keep API Controllers separate from MVC Controllers because they really are different ways of dealing with requests and responses.
Examples of things you can do in WebAPI that you can't (or at least not as easily) in MVC include:
Content Negotiation
This allows the calling client to choose the format that data will be returned in, such as XML or JSON.
OData support
This allows the caller to "filter" results on the server without the service method having to specifically support it. For instance, if you want to sort the results by first name, then this can be done simply by specifying OData query parameters
WebAPI provides a lot of power for dealing with data result sets. MVC does not provide that kind of functionality.
You would tend to use WebAPI for things like Ajax requests, or web service based requests that do not require the complexity of WCF.
RESTful API's are not specific to MVC or WebAPI. They're simply a philosophy for how you design your HTTP requests in a service. There's a lot to it really, but I won't go into it.
WCF team merged at Microsoft with MVC team. WCF is not going away, but for simple RESTFUL service call, the MVC Controller were a match made in heaven, and the modification to it allowed for a very easy Web API.
While many of us feel WCF is relatively easy, there are many who fear it and/or don't have/take time to learn it, thus they a. still use ASMX, b. still never adopted services, or NOW with Web API, are c. Very excited that they can very easily get up and running with restful web services.
So really it is a matter of comfort level, adaptation, ability to change and the Web API does have its place. It cannot replace WCF as WCF has advanced configurations with all the bindings and ability to do SOAP and not just REST, which many applications still NEED to have SOAP protocol.
MVC is optimized to serve information to a web browser client. If your client is something else, Web API will make your life easier over the long term.
Web API is a from the ground up re-write of the web stack. At the core it is much cleaner and more flexible than the 12 year old infrastructure that MVC is built on top of. Web API does not yet have the same level of tooling, add-ons, plugins as MVC, but that will come.
I am learning to create RESTful services using WCF. There are a myriad of options to choose from. I am confused as to what should i use.
1.)REST Starter kit - Seems to be obsolete
2.)WCF WEbhttp service
3.)WCF Web API
4.)ASP.NET web api
I dont want to use ASP.NET MVC to build RESTFul services. I dont like the idea of services being in the same solution structure of a presentation layer. So what is it i should use?ASP.NET web api seems to be having going down the MVC route where the requests are handled by a controller which i feel does not fit into a "Service" terminology.
Take a look a that
Microsoft support for REST is moving to ASP.NET WebApi, but you are still free to use webhttpbinding to build your api if you want. The starter kit is no longer developed nor supported.
I don't get this part though
I dont like the idea of services being in the same solution structure
of a presentation layer.
You can build a webapi project in a different assembly than your web (presentation logic) project, and the solution it's only useful for you to keep all the things in one place, it does not affect the behavior of your projects/assembly, you can still use them/develop them independently. If you don't like the "style" of webapi (it's certainly "different" from what WCF developers are used to) it's another story.
I have a MVC pattern in place where I have been developing WinForms and WebForms against. Now, I would like to move onto Silverlight and thus need to 'web services'-enable my Model layer.
Where do I start? I can't seem to find any good resources. Many talk about EF or ADO.NET Data Services. What do I need to do to my Model layer to enable it for WCF REST?
There are many approaches you can take to build your server-side
ADO.NET Data Services - here is some documentation
ASP.NET MVC - if you do decide to use ASP.NET MVC, then this tutorial shows you how to access the service from Silverlight. Essentially Tim is showing you how to access the particular REST service exposed by ASP.NET MVC, but the same techniques (WebClient, etc) can be used to talk to any REST service
Build your own WCF SOAP-based service which implements the MVC pattern. This link shows you how to build and access WCF SOAP-based services in Silverlight.
Build your own REST service which implements a MVC pattern. There is a universal way to comsume any REST service from Silverlight, which is described here. To build the rest service you can use whatever platform you choose. You may consider the WCF REST support that comes out-of-the-box in .Net 3.5, or the WCF REST Starter Kit, which builds on the out-of-the-box REST support in WCF to give you some extra features. Or you can consider any other REST service framework of your choosing.
If you are going to proceed with the technologies you are talking about then forget completely about the term REST. What these technologies allow is you to do is object remoting over HTTP with the HTTP verbs. There is nothing wrong with that, just be aware of what you are trying to achieve.
The more you read and understand about REST the more confused you will get while trying to use Silverlight 3, ADO.Net Data Services, WCF REST Starter kit. These are all fine technologies to achieve what they were designed to do. Unfortunately, you will not learn how to do REST properly from these tools.
If you really want to do REST in .Net then start looking at OpenRasta.