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.
Related
I am quite perplexed over the use of Web Api in a MVC application being developed at my company.I recently joined the project and wondering why they are using this.The application uses JQuery AJAX functionality to pull data for each Tab in a MultiTab Page without refreshing it.
The application here is neither providing data service nor consuming any Web API service.This can be easily achieved without using REST verbs.It is directly connecting to database like a typical web application.
I am holding back myself to raise this question with the team since I haven't used Web API much but has a conceptual idea.
Am I missing something here ?
Microsoft's Web API MVC technology is typically used for external components to interact with the system - not generally a requirement for a standard MVC Web Application.
With that said, I'm not perfectly clear on the architecture. A few points of note:
jQuery AJAX is a perfectly valid (and usually preferred) method to retrieve information for tab pages - it provides a SPA (Single Page Application) "feel" to the site and generally improves performance all around. This does not mean that they're using a Web API
MVC is a framework used for many web applications, including Microsoft's Web API projects as well as ASP.NET MVC Web projects. The use of MVC doesn't mean that they're using a Web API.
A RESTful approach isn't just for Web APIs. Indeed, many find it a cleaner approach when using regular MVC Web Applications, as it tends to be more semantic to what actions are actually being performed (GET to get a view, POST to post data, DELETE, etc.) There's no real reason not to use REST verbs (which are actually just HTTP verbs, but called "REST" when we use them in a certain way). The use of HTTP verbs doesn't mean that we're using a Web API.
To conclude, The MVC Web API framework is it's own technology that's similar to MVC Web Applications, but more geared towards working with non-visual requests and responses, instead tailored to programmatic interfacing.
If this is indeed a Web API being used and not a case of MVC practices that you happen to be unfamiliar with, then yes, I think it's a good question to raise (at least from a technical standpoint - politically, maybe not, but we can't answer that for you).
A typical setup is to have multiple projects, one of which is a Web Application, which makes use of shared project(s) for domain/business classes and data persistence. Additionally, a Web API project is often used to provide access to the system for external components, but this is a separate "presentation layer" project from the aforementioned Web Application.
There may be cases where a Web API application is written as the core interface between the internal system and the rest of the outside world, where the MVC Web Application then interacts with the Web API, but this is a corner case that should only be done with specific reason, in my opinion (unless I misread, this seems to be the case you're stating?)
Using both MVC and WebAPI together in a ASP.NET Web application is quite common. Whilst you can provide HTML through WebAPI and you can provide JSON through MVC it's much cleaner to use the best technology for each.
WebAPI in particular lets you define an API once and then generates JSON, XML, ... for you based on the request.
I have a standard nteir setup :-
Web server -> App server -> DB server
I have an MVC 5 web application sitting on the web server with controllers calling a WCF services project sitting on the App server. WCF services project uses EF6 to marshal data on the DB server.
I am wondering if WCF is overkill? Is there is an easier way to achieve this same architecture? I am thinking I should have gone with Web API on the app server and then just call the web API from the controllers with the HTTPClient?
Or, I could even just use a plain MVC project on the App server returning JSONResults to the MVC controller on the web server?
It depends...
You have to understand what are the benefits of each set up. This is not exhaustive, just a quick brain dump. This should give you some hints to look further as in the wild world there might be many more reasons for choosing one or another solution.
Why WCF. Are you going to have different clients to your backend ? You need some entreprisy security between clients and you backend ? With WCF you could configure Http, TCP endpoints, set message or transport security and a lot more. It could be needed for example if your doing an intranet application and you would like not only to have your UI (MVC application) but other systems going to it. If this is not needed WCF seems overkill here.
Web Api is also agreat choice if you would like to built more REST oriented api, enabling content-negotiation for different clients (different media-types). Building REST is not about issuing JSON, it's much more and this would be too long to explain it here. If your client is not only your MVC app, but you could have a need for a api for other mobile devices, OAuth authentication and the so, this could be a good way to do.
Plain MVC app would also fit if you don't have any special needs, go for it. No overhead needed. Keep It Simple And Stupid.
I hope this helps
I would not change this.
WCF is a good choice for communication between Web Tier and App Tier. I would never put my App Tier exposed to outside world, so if there is any communication to my app from outside world, it would be through Web tier only and if there is a need to support multiple clients, I would create a WebAPI on web tier and expose that.
I would keep App tier only available to Organization internal and with WCF I would have flexibility to write service code and contracts which can then be exposed over various bindings (transport, security, etc.).If you are building a service in your organization and plan to support multiple protocols, or simply use protocols other than HTTP (tcp, name pipes, udp, etc.) then WCF is indeed a good choice.
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.
We currently have an .NET 4 application that consists of Windows Service running in the background and local or remote clients (only 1-3 normally).
The clients have a WPF GUI and need some data from the windows service. Therefore, we use WCF with NamedPipe binding for a local client and NetTcp binding for remote clients. This works, but we often have problems with endpoints that are not reachable (channel faulted or not found etc.). We already try to rebuild faulted connections but it seems to be pretty fragile...
Now enter Web Api: It looks like a HTTP based stack might be more robust (no channels, no endpoints, can be self-hosted in windows service as well). There seems to be no problems with broken channels because each request is handled individually. So if something fails, you just repeat the request. (And we have experience with ASP.NET MVC from other apps, so this not new to us).
Now we are thinking what might be our best bet. Is it better to "harden" our existing WCF service (one service interface with about 15 operations) or to move the interface to Web Api and run it as HTTP requests (with JSON data)? Performance is not our main issue here...
Any ideas?
Hartmut
I recommend you stick with WCF (SOAP) services for your WPF application rather than moving to the Web API. There are a number of reasons for this. First I think we need to consider what the new Web API is trying to address - namely to provide a framework for supporting RESTful/HTTP/hypermedia services. This is likely to be a good fit for building applications that make heavy use of HTTP such as web, mobile and JavaScript applications, where you want to maximise the "reach" or interopability of your services (irrespective of platform). This is not to say that you can't use it for WPF clients but in your case, where all traffic is local to your domain, it makes more sense to stick with your current implementation.
The binding choices you have made for your services / clients sound ok to me. I would focus on why your channels are faulting and address these issues. You may also want to consider hosting your services via IIS and use WAS to expose your non-HTTP endpoints. I have had much success with this in the past and for the most part has been pretty stable. It also takes away a few of the headaches with managing your own host. If you are concerned about the TCP binding faults, then just create a new HTTP or wsHTTP endpoint and use that instead. This will provide you exactly the same transport the web api uses without having to change your programming model.
I'm developing a web app. This is more of a line-of-business app rather than a web site. I'm using ASP.NET MVC, SQL Server 2008, and I've purchased LLBLGen. I need to provide an some sort of API to third parties. For instance, if this was a medical app, third parties might need to CRUD patients, retrieve complex reports, engage certain kinds of workflows, etc.
What is the best way to do this with MVC without going to the architecture astronaut route. Do I need a whole "web service" type layer or can I re-use my controllers in MVC? Does it make sense to have this kind of API exposed through MVC? Optimally, I need a solution that involves the least amount of code repitition. I've found some stuff on doing REST with MVC but some of it is rather ambiguous and I'm not sure if it makes sense. I need a reasonable API but I'm not required to follow all the tenets of the REST religion or anything like that. I just need some sort of API in addition to providing the HTML front-end to the site, be it REST, SOAP, whatever.
Also, what are some options for dealing with URLs? Not everything in the app maps to something like site/products/product-id. Some of it involves engaging complex workflows, etc.
If you're going to have a web site and a web service then I would consider separating the data access and entities layers out from the MVC.
That way, your web service can do the same things that your website can. I would have a service layer that they both interact with. After which point the calls then go to the database and return the objects, and neither the web service nor the website should be able to interact with this layer.
This concept is also known as Separation of Concerns.
You can't/shouldn't reuse your MVC controllers in your web service. If they're so alike that they're indistinguishable, then consider writing your website to be a client of the web service, rather than being part of the same solution.