This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
ASP.NET web api: documenting/specifying a service
I'm new to Asp.net Web API. It seems there is no formal definition of the input and outputs for the Web APIs, unlike SOAP-based ones where a WSDL document contains all the schema required for requests and responses to the service. I am very familiar to this concept due to my past experiences in WCF.
How a client knows how to consume those APIs ? Does we need to provide 'examples' ?
I think your best bet is to go for ASP.NET Web API Help Page nuget package - http://nuget.org/packages/Microsoft.AspNet.WebApi.HelpPage. It's been released the same day as Web API RTM was released, that's why there is no so much info on the web about it yet, and why most people would still point you to IApiExplorer.
There is a really nice introduction screencast by Yao Huang from MSFT about how to use it - http://blogs.msdn.com/b/yaohuang1/archive/2012/08/15/introducing-the-asp-net-web-api-help-page-preview.aspx
It's not as low level as IApiExplorer (it operates on top of that) and should be more than fine for most use cases.
Also, if you are building a REST service do not use WSDL. It has not been designed to document REST services, and its much closer to RPC type of API.
ApiExplorer is the way to go for Asp.net Webapi.
Since there is no WSDL or anything for REST Apis that can exactly tell the consuming client about the operations/ contract exposed. Webapi had IApiExplorer that can be used for generating documentation of your api
Related
Maybe this is a beginner question but I can't see the answer. So I'm build a web api that is going to consume 2 web services and the perfect case scenario would be the absence of mapping request and response objects. Is there anyway to share the same interface between the webapi and the 2 webservices?
This is in .net environment, webapi is being built in MVC.
Is there any use to work in MVC web service instead of asmx and WCF web service. Can anyone please tell the difference between the three?
About WCF web services and ASPNET Web Services (ASMX), You can find side by side comparision from MSDN : Comparing ASP.NET Web Services to WCF Based on Development
If you are making MVC Application you can use both ASMX and WCF web services, But I strongly recommend to use WCF Web service for any new development.
For information, I think the more suitable Blog regarding comparison is : ASMX Vs WCF
WCF vs. ASMX
Protocols Support
WCF
HTTP
TCP
Named pipes
MSMQ
Custom
UDP
ASMX
HTTP only
Hosting
ASMX
Can be hosted only with HttpRuntime on IIS.
WCF
A WCF component can be hosted in any kind of environment in .NET 3.0, such as a console application, Windows application, or IIS.
WCF services are known as 'services' as opposed to web services because you can host services without a web server.
Self-hosting the services gives you the flexibility to use transports other than HTTP.
WCF Backwards Compatibility
The purpose of WCF is to provide a unified programming model for distributed applications.
Backwards compatibility
WCF takes all the capabilities of the existing technology stacks while not relying upon any of them.
Applications built with these earlier technologies will continue to work unchanged on systems with WCF installed.
Existing applications are able to upgrade with WCF
New WCF transacted application will work with existing transaction application built on System.Transactions
WCF & ASMX Integration
WCF can use WS-* or HTTP bindings to communicate with ASMX pages
Limitations of ASMX:
An ASMX page doesn’t tell you how to deliver it over the transports and to use a specific type of security. This is something that WCF enhances quite significantly.
ASMX has a tight coupling with the HTTP runtime and the dependence on IIS to host it. WCF can be hosted by any Windows process that is able to host the .NET Framework 3.0.
ASMX service is instantiated on a per-call basis, while WCF gives you flexibility by providing various instancing options such as Singleton, private session, per call.
ASMX provides the way for interoperability but it does not provide or guarantee end-to-end security or reliable communication.
I can't top the other post on here regarding the merits of WCF over ASMX, it is from the source (microsoft), what I would add to that post as it fails to mention the MVC Web API, is this... your question really depends on the problem you are trying to solve. If you are trying to do messaging, message queues, or lower level tcp/ip it will still be WCF..
I'm a modern world programmer, as lazy as they come.. both ASMX and WCF technologies are starting to feel a bit dated to me, for example a typical WCF implementation will probably have a hefty XML configuration associated to it, if this is the way you are used to working then it will probably feel natural.
I like type safety and hate magic strings and further hate digging around in large XML, to my mind this is the path of the runtime error.
If you have used the MVC framework to create a web application then there is pretty much a zero learning curve to using the mvc webapi.
All the standard things like routes, models and controllers still apply in exactly the same way, all the HTTP verbs are there to be used...
With minimal effort all your routes and controllers can be used in a completely type safe way (no strings), so if it is broken then it probably doesn't compile....
Also it is much easier to write a unit test to exercise a controller than it is to unit test a ServiceContract
I'm not certain but I'd expect the MVC route to lend itself to IoC/DI better than WCF for the same reason above, but I'm prepared to be wrong on that.
Can you tell I'm biased.
This is a subjective question and with regards to the difference between the 3; WCF is more suited to communication between layers, asmx is basically what we used before wcf came along and due to the flexibility of mvc, it can be used in a number of senarios. WCF is however great for implementing OData services.
I personally use MVC to implement the web service on the client tier for AJAX interactions and have done so on several projects. The advantages are that I do not have a separate project and as such the front end stack is light weight and DRY, more efficient and organising code in this way makes more logical sense to me.
IMHO wcf has too large an overhead and is overly complex for simple JSON serialization. I personally think there is a case for using MVC in an n-tier architectural site instead of WCF.
This article looks at using this in the infamous NerdDinnerd project nerd dinner rest
There are several frameworks such as OpenRasta, but I find that the standard mvc.net tools are more than sufficient.
Also, a good article by haacked here: haacked.com
I'm on the core team that maintains ServiceStack - another very popular choice to build REST-based services on .NET / Mono.
Supports REST, SOAP and MQ based services
In addition to REST-based services you can re-use your same services to Support both SOAP and REST-based endpoints. ServiceStack also includes the .NET's fastest JSON, JSV and CSV text serializers. Here's an earlier answer comparing its advantages over WCF and WebApi.
Succinct, Typed, End-to-end API
ServiceStack also includes typed generic ServiceClients in all the major supported formats including: JSON, XML, JSV, SOAP 1.1/1.2 as well as the super fast binary ProtoBuf and MessagePack formats.
ServiceStack's generic service clients offer the most succinct, typed end-to-end client/server API without any code-gen.
ServiceStack Overview slides
The ServiceStack Overview Talk at this years MonkeySpace has a good intro into ServiceStack and its advantages.
In the last few years, I have seen the rise of many Web APIs - services exposed over plain HTTP rather than through a more formal service contract (like SOAP or WS*). Microsoft has just launched a new framework called "ASP.NET Web API" hat makes it easy to build HTTP services that reach a broad range of clients. Event if I am a .net fan, it is another communication framework (after asmx, wcf, ria, ...). Now, working as an happy architect, I have to take decision over technologies.
Is Asp.net Web Api really a good choice for a new architecture? Remember Linq2Sql, I do not want to invest in a "disposable" api.
Is there still a use for WebBindings in WCF?
The problem with this question, in terms of it being a stack overflow question, is that it's basically subjective. As a result, I'm pretty sure it'll be closed - but I'm going to stick my 2 pence (it's more like £2 actually) anyway and if it gets closed so be it.
First Linq2Sql isn't 'disposable' - it's still there and not going to go away. It's not being developed - that's another matter entirely.
Anyway - The Asp.Net Web API is a formalization of REST web service support by many people from the same team that work(ed) on Asp.Net MVC and uses a very similar approach to extensibility, pipelining, cross-cutting concerns (e.g. authentication, logging, validation) and such. Whether you use it or not is entirely down to whether you are intending to develop RESTful web services. If you are, and you're on .Net 4+, then, in my opinion, you'd be mad not to.
The overall architecture in the Web API is very good and you can extend most of it without too much effort at all. In particular, the way that they have handled content negotiation is very very nice, making it trivial to, for example, support JSON requests but returning XML responses just because a client sends Content-Type:application/json and Accepts:application/xml.
As a server technology it's also very very fast; partly because it's entirely asynchronous (increasing scalability) but also because the stack between a request coming in, to your code being called, is very shallow.
Not only that but you can host it in both IIS and in any .Net application also - which increases your hosting options but also makes it a candidate for intra-network communications within a common network (i.e. non-internet) environment.
If, however, you want to write a SOAP or WS-HTTP service then, no, the Web API is not for you - you'd stick with WCF.
In short - you need to think of the Asp.Net Web API purely as a server and client technology running on .Net as opposed to a protocol or web architecture. It enables you to build RESTful web services - you can also do that in MVC, WebForms (if you really wanted to), .ashx handlers, or by writing your own HttpListener.
Which of those you choose is entirely up to you to decide.
We can call ASP.NET Web API a replacer of WCF Web API.
It will support more platform oriented service.
I'm developing an ASP.NET MVC 3 application. I need this application to make use of an API I also need to implement. The API should both be available from ASP.NET MVC controller actions and Ajax. Now it is quite easy to make an API using ASP.NET MVC, but is it possible to use this from other ASP.NET MVC website actions? I guess the WCF is quite easy to use as it is just a service reference.
Other users of the API could be Windows Phone and iPhone.
Update:
Many only sees the API as a place where you consume data, but what about the part where you want to execute commands or do stuff, like add customer or change foo?
You may want to check our new WCF web API that was announced at PDC. We recently released a big upgrade. WCF Web API is designed specifically for allowing you to expose APIs to a range of clients in a pure HTTP manner. It is lightweight, offers a nice configuration story (no configuration files) and also is much easier to test.
You can download the bits at wcf.codeplex.com. It includes various samples, and there is also a set of NuGet packs for getting you started. Search for webapi.all on NuGet.
The way I like to do this is with RESTful controller actions. You can return JSON and use your calls with JavaScript on your own site. Other websites would almost certainly understand JSON and so they'd be able to consume your API pretty easily. This is much easier to write and test than a heavy WCF layer.
Check out this question for some example REST frameworks for MVC:
ASP.NET MVC REST frameworks
One of the newer ways of accomplishing data feeds is using OData. Scott Hanselman has a great introduction to it in Creating an OData API for StackOverflow including XML and JSON in 30 minutes.
It allows you to even throw LINQ queries into your URLs to retrieve exactly the data you need.
Open Data Protocol (Official site)
Open Data Protocol (MSDN, Microsoft)
WCF JSON binding was really terrible last time I used it. WCF also comes with all sorts of crazy rules about streams and how you have to use [MessageBody] attributes for everything.
It was a real PITA to me.
I knew I've answered something like this before:
What is the best way to implement a RESTful architecture in .NET today?
A 3rd party site sends its notifications after my web application has completed some action in order to notify me of its success. Receiving a notification item requires a response back to the 3rd party server (URL) with the a containing the value "accepted".
I have never user SOAP and with the basic info found I'm a bit lost for the case of asp.net mvc. Are there any good links showing the principle of receiving and sending SOAP responses?
Tutorials / information may be presented in other languages such as java, asp.net (classic) or something. I need to get a general idea since googling on SOAP has not given me anything for the past few hours.
You need to learn a little about WCF. See the WCF Developer Center, especially the Beginners Guide.
What you want is to create a simple WCF service that corresponds to the WSDL that they will give you. You will need to implement only the operation (method) that they will call to notify you. You can host a WCF service in IIS along with the rest of your application.
The issue will be how to correlate the notifications with the page you're on in your MVC application.
I don't think this is specific to ASP.NET MVC really. If you have a WSDL for their web service, just use that to generate stub classes using either wsdl.exe or by adding a web reference to your project, then call the web service from your controller.
If I remember correctly SOAP is basically xml requests and responses.
You might want to look into WSDL (Web Service Definition Language) to avoid having to deal with raw data, and you would likely find a great deal of tutorials on wsdl as well.